<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: PS1 variable being set for in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289243#M181798</link>
    <description>It is VERY common for workstation users or users that run CDE and terminal emulators to access HP-UX to not login 'normally'. This is because the default for CDE (and the obsolete VUE product) is for dtterm, xterm and hpterm NOT to run /etc/profile or .profile during login. (similarly for csh user, the /etc/csh.login file and .cshrc) The reasons behind the Xwindow behavior are obscure but nevertheless quite frustrating.&lt;BR /&gt; &lt;BR /&gt;However, there is an easy fix: In each $HOME directory (the home directory for each user login), perform this task once:&lt;BR /&gt; &lt;BR /&gt;echo "*loginShell: true" &amp;gt;&amp;gt; $HOME/.Xdefaults&lt;BR /&gt; &lt;BR /&gt;Now when the user starts a remote terminal window such as hpterm or dtterm or xterm, the 'normal' Unix login process will be followed and both /etc/profile (the usual place to put ORACLE_HOME and other environmental settings) and $HOME/.profile will be executed.&lt;BR /&gt; &lt;BR /&gt;Note that the CDE variable DTSOURCEPROFILE only affects .profile so it misses the important /etc/profile file. And you can also add the loginShell directive to the startup of dtterm, hpterm or xterm (the option is -ls).&lt;BR /&gt; &lt;BR /&gt;Now if you do not use Xwindows, then verify that your users have a standard shell (/usr/bin/sh or /usr/bin/ksh). Shells like csh, bash, tcsh, etc, should ALWAYS be avoided (better yet: forbidden) on production servers as they create sysadmin nightmares for support. And to see if /etc/profile and the local .profile are really being executed, put a print or an echo at the front of both files so you know they are being run:&lt;BR /&gt; &lt;BR /&gt;echo "...Now running /etc/profile..."&lt;BR /&gt; &lt;BR /&gt;or &lt;BR /&gt; &lt;BR /&gt;echo "...Now running $HOME/.profile..."&lt;BR /&gt; &lt;BR /&gt;If this works OK but the values are still not set, use the shell script trace option as in:&lt;BR /&gt; &lt;BR /&gt;sh -x /etc/profile&lt;BR /&gt; &lt;BR /&gt;or&lt;BR /&gt; &lt;BR /&gt;sh -x $HOME/.profile&lt;BR /&gt; &lt;BR /&gt;For users with a problem.</description>
    <pubDate>Thu, 27 May 2004 21:04:23 GMT</pubDate>
    <dc:creator>Bill Hassell</dc:creator>
    <dc:date>2004-05-27T21:04:23Z</dc:date>
    <item>
      <title>PS1 variable being set for</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289240#M181795</link>
      <description>I am running hp-ux 11.i with BASH 2.05.&lt;BR /&gt;&lt;BR /&gt;I have added the line:&lt;BR /&gt;export PS1="\u@\h:\w\\n \#\\$ "&lt;BR /&gt;in /etc/profile.  This file has been linked to /etc/dt/config/Xsession.d/profile so that it will be read by xwindow logons as well.&lt;BR /&gt;&lt;BR /&gt;The problem is that the PS1 varable is not working when loging in to xwindows.  Other variables in profile are exported fine.&lt;BR /&gt;&lt;BR /&gt;I have searched for other locations that may be ovewriting this PS1 variable and have found none.&lt;BR /&gt;&lt;BR /&gt;Any suggestions on this would be appreciated.&lt;BR /&gt;&lt;BR /&gt;Thanks in advance,&lt;BR /&gt;&lt;BR /&gt;Keith&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 27 May 2004 14:48:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289240#M181795</guid>
      <dc:creator>Keith Winger</dc:creator>
      <dc:date>2004-05-27T14:48:26Z</dc:date>
    </item>
    <item>
      <title>Re: PS1 variable being set for</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289241#M181796</link>
      <description>Check:&lt;BR /&gt;&lt;BR /&gt;DTSOURCEPROFILE=true&lt;BR /&gt;&lt;BR /&gt;in .dtprofile&lt;BR /&gt;&lt;BR /&gt;Rgds...Geoff</description>
      <pubDate>Thu, 27 May 2004 15:15:24 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289241#M181796</guid>
      <dc:creator>Geoff Wild</dc:creator>
      <dc:date>2004-05-27T15:15:24Z</dc:date>
    </item>
    <item>
      <title>Re: PS1 variable being set for</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289242#M181797</link>
      <description>Geoff&lt;BR /&gt;Thanks for the response&lt;BR /&gt;&lt;BR /&gt;DTSOURCEPROFILE is currently set to true in .dtprofile.&lt;BR /&gt;&lt;BR /&gt;I have tried to rem this line out and it has not made any difference to the PS1 variable.  When I rem it out, other variables, including the DISPLAY variable does not get set correctly.  Therefore I currently have DTSOURCEPROFILE=true.&lt;BR /&gt;&lt;BR /&gt;Keith</description>
      <pubDate>Thu, 27 May 2004 15:40:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289242#M181797</guid>
      <dc:creator>Keith Winger</dc:creator>
      <dc:date>2004-05-27T15:40:02Z</dc:date>
    </item>
    <item>
      <title>Re: PS1 variable being set for</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289243#M181798</link>
      <description>It is VERY common for workstation users or users that run CDE and terminal emulators to access HP-UX to not login 'normally'. This is because the default for CDE (and the obsolete VUE product) is for dtterm, xterm and hpterm NOT to run /etc/profile or .profile during login. (similarly for csh user, the /etc/csh.login file and .cshrc) The reasons behind the Xwindow behavior are obscure but nevertheless quite frustrating.&lt;BR /&gt; &lt;BR /&gt;However, there is an easy fix: In each $HOME directory (the home directory for each user login), perform this task once:&lt;BR /&gt; &lt;BR /&gt;echo "*loginShell: true" &amp;gt;&amp;gt; $HOME/.Xdefaults&lt;BR /&gt; &lt;BR /&gt;Now when the user starts a remote terminal window such as hpterm or dtterm or xterm, the 'normal' Unix login process will be followed and both /etc/profile (the usual place to put ORACLE_HOME and other environmental settings) and $HOME/.profile will be executed.&lt;BR /&gt; &lt;BR /&gt;Note that the CDE variable DTSOURCEPROFILE only affects .profile so it misses the important /etc/profile file. And you can also add the loginShell directive to the startup of dtterm, hpterm or xterm (the option is -ls).&lt;BR /&gt; &lt;BR /&gt;Now if you do not use Xwindows, then verify that your users have a standard shell (/usr/bin/sh or /usr/bin/ksh). Shells like csh, bash, tcsh, etc, should ALWAYS be avoided (better yet: forbidden) on production servers as they create sysadmin nightmares for support. And to see if /etc/profile and the local .profile are really being executed, put a print or an echo at the front of both files so you know they are being run:&lt;BR /&gt; &lt;BR /&gt;echo "...Now running /etc/profile..."&lt;BR /&gt; &lt;BR /&gt;or &lt;BR /&gt; &lt;BR /&gt;echo "...Now running $HOME/.profile..."&lt;BR /&gt; &lt;BR /&gt;If this works OK but the values are still not set, use the shell script trace option as in:&lt;BR /&gt; &lt;BR /&gt;sh -x /etc/profile&lt;BR /&gt; &lt;BR /&gt;or&lt;BR /&gt; &lt;BR /&gt;sh -x $HOME/.profile&lt;BR /&gt; &lt;BR /&gt;For users with a problem.</description>
      <pubDate>Thu, 27 May 2004 21:04:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/ps1-variable-being-set-for/m-p/3289243#M181798</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2004-05-27T21:04:23Z</dc:date>
    </item>
  </channel>
</rss>

