automatic change default working directory after graphical login - Redhat

This is a discussion on automatic change default working directory after graphical login - Redhat ; short description of the problem: I would like to automagically change the working directory from $HOME to, for example, /proj/$USER after the $USER logs into the machine via the graphical (GUI) login (aka gdm). So, when the $USER opens new ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: automatic change default working directory after graphical login

  1. automatic change default working directory after graphical login

    short description of the problem:
    I would like to automagically change the working directory from $HOME
    to, for example, /proj/$USER after the $USER logs into the machine via
    the graphical (GUI) login (aka gdm). So, when the $USER opens new
    terminal, he/she should be in /proj/$USER and __not__ in $HOME
    [side note: I am using tsch as my $SHELL]

    oo: no, putting 'cd /proj/$USER' into .cshrc is _not_ the solution

    oo: yes, putting 'cd /proj/$USER' into .login works if the user logs
    into the machine using CLI login and then starts the desktop with
    'startx' OR if he/she logs to the machine via ssh|telnet. It does not
    work for gdm (aka graphical login)

    oo: no, adding 'cd /proj/$USER' to the file Default or Xsession does
    __not__ work.

    /etc/gdm/PostLogin/Default
    /etc/gdm/PreSession/Default
    /etc/gdm/Xsession

    oo: no, I do not want to change variable $HOME to point to /proj/$USER

    oo: no, I do not want to modify /etc/passwd file

    Simply put, I am out of ideas. Any hint, RTFM pointer or solution is
    appreciated.

  2. Re: automatic change default working directory after graphical login

    geda.mail@gmail.com wrote:
    > short description of the problem:
    > I would like to automagically change the working directory from $HOME
    > to, for example, /proj/$USER after the $USER logs into the machine via
    > the graphical (GUI) login (aka gdm). So, when the $USER opens new
    > terminal, he/she should be in /proj/$USER and __not__ in $HOME
    > [side note: I am using tsch as my $SHELL]
    >
    > oo: no, putting 'cd /proj/$USER' into .cshrc is _not_ the solution
    >
    > oo: yes, putting 'cd /proj/$USER' into .login works if the user logs
    > into the machine using CLI login and then starts the desktop with
    > 'startx' OR if he/she logs to the machine via ssh|telnet. It does not
    > work for gdm (aka graphical login)


    OK, *WHY*????

    That said, perhaps you can look at '.xinitrc' to do the cd first, then start
    up your X session? The default one is usually called by the 'startx' init
    script: you can get some hints from that, or from the 'gdmrc' files if you use
    gdm to provide graphical logins.

    > oo: no, adding 'cd /proj/$USER' to the file Default or Xsession does
    > __not__ work.
    >
    > /etc/gdm/PostLogin/Default
    > /etc/gdm/PreSession/Default
    > /etc/gdm/Xsession
    >
    > oo: no, I do not want to change variable $HOME to point to /proj/$USER
    >
    > oo: no, I do not want to modify /etc/passwd file
    >
    > Simply put, I am out of ideas. Any hint, RTFM pointer or solution is
    > appreciated.


  3. Re: automatic change default working directory after graphical login

    On May 3, 6:46 pm, Nico Kadel-Garcia wrote:
    > geda.m...@gmail.com wrote:
    > > short description of the problem:
    > > I would like to automagically change the working directory from $HOME
    > > to, for example, /proj/$USER after the $USER logs into the machine via
    > > the graphical (GUI) login (aka gdm). So, when the $USER opens new
    > > terminal, he/she should be in /proj/$USER and __not__ in $HOME
    > > [side note: I am using tsch as my $SHELL]

    >
    > > A) oo: no, putting 'cd /proj/$USER' into .cshrc is _not_ the solution

    >
    > > B) oo: yes, putting 'cd /proj/$USER' into .login works if the user logs
    > > into the machine using CLI login and then starts the desktop with
    > > 'startx' OR if he/she logs to the machine via ssh|telnet. It does not
    > > work for gdm (aka graphical login)

    >
    > OK, *WHY*????
    >


    Is your "WHY???" related to A) or to B) ???

    If it is related to A, the explanation is simple:
    because the following script will ___not___ work correctly
    -------------------------------
    #!/bin/tcsh

    echo "Hello World" > test_file

    exit
    --------------------------------

    Let suppose, the user will launch the scrip from /aaa/bbb/cccc. The
    sript will NOT create the test_file in the current working directory.
    The file will be created in /proj/$USER, which does not make sense...
    it is not intuitive.

    Yes, I know, #!/bin/tcsh -f can solve the problem. My users wrote a
    lot of scripts already without a switch -f so, most of them will not
    work correctly anymore

    If the 'WHY???' is related to B) then I do not know the answer. I
    do not know why is .login NOT executed if the $USER login into the
    machine via gdm.

    SOLUTION:
    click on this link:
    http://mail.gnome.org/archives/gdm-l.../msg00008.html
    or/and
    http://mail.gnome.org/archives/gdm-l.../msg00006.html
    or/and
    http://mail.gnome.org/archives/gdm-l.../msg00007.html

  4. Re: automatic change default working directory after graphical login

    geda.mail@gmail.com wrote:
    > On May 3, 6:46 pm, Nico Kadel-Garcia wrote:
    >> geda.m...@gmail.com wrote:
    >>> short description of the problem:
    >>> I would like to automagically change the working directory from $HOME
    >>> to, for example, /proj/$USER after the $USER logs into the machine via
    >>> the graphical (GUI) login (aka gdm). So, when the $USER opens new
    >>> terminal, he/she should be in /proj/$USER and __not__ in $HOME
    >>> [side note: I am using tsch as my $SHELL]
    >>> A) oo: no, putting 'cd /proj/$USER' into .cshrc is _not_ the solution
    >>> B) oo: yes, putting 'cd /proj/$USER' into .login works if the user logs
    >>> into the machine using CLI login and then starts the desktop with
    >>> 'startx' OR if he/she logs to the machine via ssh|telnet. It does not
    >>> work for gdm (aka graphical login)

    >> OK, *WHY*????
    >>

    >
    > Is your "WHY???" related to A) or to B) ???


    No, it's related to the first paragraph, wanting to change the operating
    directory of an X startup to the /proj/$USER.

    $CWD, or 'current working directory', is associated with the
    current-working-directory fo the X sesseion when it starts. This state will be
    associated with anything else started in that window, but it's not clear to me
    why you want to do this. It won't change your $HOME, or where your
    configuration files are kept, etc. So why do you want to do this?

    > If it is related to A, the explanation is simple:
    > because the following script will ___not___ work correctly
    > -------------------------------
    > #!/bin/tcsh
    >
    > echo "Hello World" > test_file
    >
    > exit
    > --------------------------------
    >
    > Let suppose, the user will launch the scrip from /aaa/bbb/cccc. The
    > sript will NOT create the test_file in the current working directory.
    > The file will be created in /proj/$USER, which does not make sense...
    > it is not intuitive.
    >
    > Yes, I know, #!/bin/tcsh -f can solve the problem. My users wrote a
    > lot of scripts already without a switch -f so, most of them will not
    > work correctly anymore
    >
    > If the 'WHY???' is related to B) then I do not know the answer. I
    > do not know why is .login NOT executed if the $USER login into the
    > machine via gdm.


    Oooff. The vagaries of what .files get executed is a black art. I believe this
    one has to do with gdm starting up a shell, not a login session, to preserve
    the various environmental settings of the X session.

    > SOLUTION:
    > click on this link:
    > http://mail.gnome.org/archives/gdm-l.../msg00008.html
    > or/and
    > http://mail.gnome.org/archives/gdm-l.../msg00006.html
    > or/and
    > http://mail.gnome.org/archives/gdm-l.../msg00007.html


  5. Re: automatic change default working directory after graphical login

    On 4 maj, 04:32, Nico Kadel-Garcia wrote:

    > >> OK, *WHY*????

    >
    > > Is your "WHY???" related to A) or to B) ???

    >
    > No, it's related to the first paragraph, wanting to change the operating
    > directory of an X startup to the /proj/$USER.
    >
    > $CWD, or 'current working directory', is associated with the
    > current-working-directory fo the X sesseion when it starts. This state will be
    > associated with anything else started in that window, but it's not clear to me
    > why you want to do this. It won't change your $HOME, or where your
    > configuration files are kept, etc. So why do you want to do this?


    Because I do not want to change system variable $HOME. I still want
    that
    all the scripts and all the settings are stored and used from $HOME.
    I just want that the user starts working automagically in /proj/
    $USER after login
    and not $HOME.

    > > If it is related to A, the explanation is simple:
    > > because the following script will ___not___ work correctly
    > > -------------------------------
    > > #!/bin/tcsh

    >
    > > echo "Hello World" > test_file

    >
    > > exit
    > > --------------------------------

    >
    > > Let suppose, the user will launch the scrip from /aaa/bbb/cccc. The
    > > sript will NOT create the test_file in the current working directory.
    > > The file will be created in /proj/$USER, which does not make sense...
    > > it is not intuitive.

    >
    > > Yes, I know, #!/bin/tcsh -f can solve the problem. My users wrote a
    > > lot of scripts already without a switch -f so, most of them will not
    > > work correctly anymore

    >
    > > If the 'WHY???' is related to B) then I do not know the answer. I
    > > do not know why is .login NOT executed if the $USER login into the
    > > machine via gdm.

    >
    > Oooff. The vagaries of what .files get executed is a black art. I believe this
    > one has to do with gdm starting up a shell, not a login session, to preserve
    > the various environmental settings of the X session.


    No, it is not black art. It follows UNIX rules just fine.

    It seem that I was not clear with my explanation for "why putting cd /
    proj/$USER into .cshrc is NOT a solution". Take a look to the 'Hello
    World' script above.
    The script starts with "#!/bin/tcsh", which is OK and it must be
    there.
    The net result of this 'shebang' http://en.wikipedia.org/wiki/Shebang_(Unix)
    is that the script itself will be executed in the directory /proj/
    $USER, the output file 'test_file' will be created in /proj/$USER and
    not in /aaa/bbb/cccc, where the script was started from. Reminder: the
    'shebang' executes (sources) .cshrc by default.

    So, the result of the 'Hello World' script is not very intuitive for
    the the end user, therefore 'cd /proj/$USER' does not belong
    into .cshrc.
    Yes, I know, #!/bin/tcsh -f could be (and it is) a solution/
    workaround.
    Since my users wrote a lot of tcsh scripts in the past 5 years, the
    workaround, unfortunately, it is not very practical. Their scripts
    will not work any more in the same way as they worked years ago. I
    would start getting a lot of phone calls stating 'grrr.. my script
    does not work any more ...yesterday, it worked OK'.
    The users expect the file test_file to be saved in the directory where
    they started the 'Hello World' script.

  6. Re: automatic change default working directory after graphical login

    geda.mail@gmail.com wrote:
    > On 4 maj, 04:32, Nico Kadel-Garcia wrote:
    >
    >>>> OK, *WHY*????
    >>> Is your "WHY???" related to A) or to B) ???

    >> No, it's related to the first paragraph, wanting to change the operating
    >> directory of an X startup to the /proj/$USER.
    >>
    >> $CWD, or 'current working directory', is associated with the
    >> current-working-directory fo the X sesseion when it starts. This state will be
    >> associated with anything else started in that window, but it's not clear to me
    >> why you want to do this. It won't change your $HOME, or where your
    >> configuration files are kept, etc. So why do you want to do this?

    >
    > Because I do not want to change system variable $HOME. I still want
    > that
    > all the scripts and all the settings are stored and used from $HOME.
    > I just want that the user starts working automagically in /proj/
    > $USER after login
    > and not $HOME.
    >
    >>> If it is related to A, the explanation is simple:
    >>> because the following script will ___not___ work correctly
    >>> -------------------------------
    >>> #!/bin/tcsh
    >>> echo "Hello World" > test_file
    >>> exit
    >>> --------------------------------
    >>> Let suppose, the user will launch the scrip from /aaa/bbb/cccc. The
    >>> sript will NOT create the test_file in the current working directory.
    >>> The file will be created in /proj/$USER, which does not make sense...
    >>> it is not intuitive.
    >>> Yes, I know, #!/bin/tcsh -f can solve the problem. My users wrote a
    >>> lot of scripts already without a switch -f so, most of them will not
    >>> work correctly anymore
    >>> If the 'WHY???' is related to B) then I do not know the answer. I
    >>> do not know why is .login NOT executed if the $USER login into the
    >>> machine via gdm.

    >> Oooff. The vagaries of what .files get executed is a black art. I believe this
    >> one has to do with gdm starting up a shell, not a login session, to preserve
    >> the various environmental settings of the X session.

    >
    > No, it is not black art. It follows UNIX rules just fine.


    Yes, and protein chemistry follows the laws of thermodynamics. Doesn't mean
    it's not so complex and filled with vagaries as to drive even experts nuts.

    To see what I mean, please take a look at what's actually *in* system .login,
    ..cshrc, .xinitrc, .gdmrc, etc. files. Almost every distribution does some odd
    things, and many shells do their own oddnesses as well. So advice from the net
    to 'put this in /etc/profile' can cause disaster for a lot of other people
    without some thought and study.

    The vagaries you're analyzing here are just the sort of thing I mean. And
    believe you me, I sympathize: I don't know if you've ever taken apart
    wu-imapd, but it believes that every file in your home directory is a mail
    file, and so it would try and analyze files saved locally by your IMAP client.
    And then your poor client would *recurse* its way down these saved mail
    folders. Nasty, nasty, nasty business.

    > It seem that I was not clear with my explanation for "why putting cd /
    > proj/$USER into .cshrc is NOT a solution". Take a look to the 'Hello
    > World' script above.
    > The script starts with "#!/bin/tcsh", which is OK and it must be
    > there.


    And it makes clear what you're really trying to achieve. Thank you for
    explaining it.

    > The net result of this 'shebang' http://en.wikipedia.org/wiki/Shebang_(Unix)
    > is that the script itself will be executed in the directory /proj/
    > $USER, the output file 'test_file' will be created in /proj/$USER and
    > not in /aaa/bbb/cccc, where the script was started from. Reminder: the
    > 'shebang' executes (sources) .cshrc by default.
    >
    > So, the result of the 'Hello World' script is not very intuitive for
    > the the end user, therefore 'cd /proj/$USER' does not belong
    > into .cshrc.


    Oh, yes, agreed.

    > Yes, I know, #!/bin/tcsh -f could be (and it is) a solution/
    > workaround.
    > Since my users wrote a lot of tcsh scripts in the past 5 years, the
    > workaround, unfortunately, it is not very practical. Their scripts
    > will not work any more in the same way as they worked years ago. I
    > would start getting a lot of phone calls stating 'grrr.. my script
    > does not work any more ...yesterday, it worked OK'.
    > The users expect the file test_file to be saved in the directory where
    > they started the 'Hello World' script.


    Now, me, I'd move aside the 'test_file' to 'test_file.bin', and put a wrapper
    in front of it to execute 'cd test_file: test_file.bin $*'. But that's another
    approach.

  7. Re: automatic change default working directory after graphical login

    geda.mail@gmail.com wrote:
    > On 4 maj, 04:32, Nico Kadel-Garcia wrote:
    >
    >>>> OK, *WHY*????
    >>> Is your "WHY???" related to A) or to B) ???

    >> No, it's related to the first paragraph, wanting to change the operating
    >> directory of an X startup to the /proj/$USER.
    >>
    >> $CWD, or 'current working directory', is associated with the
    >> current-working-directory fo the X sesseion when it starts. This state will be
    >> associated with anything else started in that window, but it's not clear to me
    >> why you want to do this. It won't change your $HOME, or where your
    >> configuration files are kept, etc. So why do you want to do this?

    >
    > Because I do not want to change system variable $HOME. I still want
    > that
    > all the scripts and all the settings are stored and used from $HOME.
    > I just want that the user starts working automagically in /proj/
    > $USER after login
    > and not $HOME.
    >
    >>> If it is related to A, the explanation is simple:
    >>> because the following script will ___not___ work correctly
    >>> -------------------------------
    >>> #!/bin/tcsh
    >>> echo "Hello World" > test_file
    >>> exit
    >>> --------------------------------
    >>> Let suppose, the user will launch the scrip from /aaa/bbb/cccc. The
    >>> sript will NOT create the test_file in the current working directory.
    >>> The file will be created in /proj/$USER, which does not make sense...
    >>> it is not intuitive.
    >>> Yes, I know, #!/bin/tcsh -f can solve the problem. My users wrote a
    >>> lot of scripts already without a switch -f so, most of them will not
    >>> work correctly anymore
    >>> If the 'WHY???' is related to B) then I do not know the answer. I
    >>> do not know why is .login NOT executed if the $USER login into the
    >>> machine via gdm.

    >> Oooff. The vagaries of what .files get executed is a black art. I believe this
    >> one has to do with gdm starting up a shell, not a login session, to preserve
    >> the various environmental settings of the X session.

    >
    > No, it is not black art. It follows UNIX rules just fine.


    Yes, and protein chemistry follows the laws of thermodynamics. Doesn't mean
    it's not so complex and filled with vagaries as to drive even experts nuts.

    To see what I mean, please take a look at what's actually *in* system .login,
    ..cshrc, .xinitrc, .gdmrc, etc. files. Almost every distribution does some odd
    things, and many shells do their own oddnesses as well. So advice from the net
    to 'put this in /etc/profile' can cause disaster for a lot of other people
    without some thought and study.

    The vagaries you're analyzing here are just the sort of thing I mean. And
    believe you me, I sympathize: I don't know if you've ever taken apart
    wu-imapd, but it believes that every file in your home directory is a mail
    file, and so it would try and analyze files saved locally by your IMAP client.
    And then your poor client would *recurse* its way down these saved mail
    folders. Nasty, nasty, nasty business.

    > It seem that I was not clear with my explanation for "why putting cd /
    > proj/$USER into .cshrc is NOT a solution". Take a look to the 'Hello
    > World' script above.
    > The script starts with "#!/bin/tcsh", which is OK and it must be
    > there.


    And it makes clear what you're really trying to achieve. Thank you for
    explaining it.

    > The net result of this 'shebang' http://en.wikipedia.org/wiki/Shebang_(Unix)
    > is that the script itself will be executed in the directory /proj/
    > $USER, the output file 'test_file' will be created in /proj/$USER and
    > not in /aaa/bbb/cccc, where the script was started from. Reminder: the
    > 'shebang' executes (sources) .cshrc by default.
    >
    > So, the result of the 'Hello World' script is not very intuitive for
    > the the end user, therefore 'cd /proj/$USER' does not belong
    > into .cshrc.


    Oh, yes, agreed.

    > Yes, I know, #!/bin/tcsh -f could be (and it is) a solution/
    > workaround.
    > Since my users wrote a lot of tcsh scripts in the past 5 years, the
    > workaround, unfortunately, it is not very practical. Their scripts
    > will not work any more in the same way as they worked years ago. I
    > would start getting a lot of phone calls stating 'grrr.. my script
    > does not work any more ...yesterday, it worked OK'.
    > The users expect the file test_file to be saved in the directory where
    > they started the 'Hello World' script.


    Now, me, I'd move aside the 'test_file' to 'test_file.bin', and put a wrapper
    in front of it to execute 'cd test_file: test_file.bin $*'. But that's another
    approach.

+ Reply to Thread