urxvt -e <cmd> and the SHELL environmental variable

[Dominique Michel]

Working on making fvwm-crystal to run fine with freebsd. I saw that when I am into a terminal, urxvt -e mc try to run urxvt, but fail to run the command and exit. In the user environment, SHELL is defined as /bin/sh.

If I run SHELL=sh urxvt -e mc, it succeed. Fvwm-crystal can use several terminals with different internal functions, and as different terminals are using different syntax to run commands, it is a few intermediate functions that make the whole thing to work. The issue is that this $SHELL issue break that.

As a workaround, I put into the main fvwm-crystal file that call fvwm with the fvwm-crystal config, before that call:

SHELL="sh"
export SHELL

That imply that fvwm and all the software launched from it will use it. Is it a better or safer alternative to do that? I would prefer to change a system option into freebsd, so I can remove that workaround and not have to add more complexity into the already relatively complex intermediate functions in fvwm-crystal.

 

[Dominique Michel]

As a workaround, I put into the main fvwm-crystal file that call fvwm with the fvwm-crystal config, before that call:

SHELL="sh"
export SHELL

I found a better solution, it is still a hack, but it use an absolute local path and it solve the missing subshell issue I got with mc at the same time:

SHELL="/usr/local/bin/bash"
export SHELL

 

[chrbr]

Dear Dominique Michel ,
if it is an issue with mc only, it might be related to the subshell problem. Please see the options -u and -U. On my system using awesome, xfce4-terminal and fish running urxvt -e mcworks.

 

[Dominique Michel]

Dear Dominique Michel ,
if it is an issue with mc only, it might be related to the subshell problem. Please see the options -u and -U. On my system using awesome, xfce4-terminal and fish running urxvt -e mcworks.

Hi chrbr,
I searched the forum and with google for the mc subshell issue, and it is a patch into the mc port that disable it when sh is in use. I try with csh and get the same issue. With other shell like bash or fish, mc is not affected by that patch and its subshell is working fine.

My goal is to get fvwm.crystal to run smoothly with freebsd. I am a freebsd newbie, and during the installation, when making my user, I accepted the default choices when making my user, and get that SHEL=/bin/sh. As an user, I prefer bash, but to add freebsd support into fvwm-crystal, I prefer that default choice.

But the main issue remain that, when I am into /bin/sh, urxwt -e <cmd> fail, and succeed as it should in bash. My workaround works fine, and as fvwm-crystal already depends on bash for some of its scripting, I am sure it will be installed into the user system.

 

[Dominique Michel]

But the main issue remain that, when I am into /bin/sh, urxwt -e <cmd> fail, and succeed as it should in bash. My workaround works fine, and as fvwm-crystal already depends on bash for some of its scripting, I am sure it will be installed into the user system.

But the consequence of my hack is that the user will be forced into bash when he's running fvwm-crystal, and I would really prefer to find another solution.

 

[Dominique Michel]

Back in /bin/sh. In fact this have to do with that mc subshell. If I run in sh urxvt -e emacs, it works fine. But mc fait to launch even from inside the application menu. And that normal because in its desktop file, mc use Exec mc.

And worst, if in ~./.shrc, I add alias mc='env SHELL=/usr/local/bin/bash mc', it works when insinde urxvt or another terminal i run mc, but mc fail if I run urxvt -e mc, which in turn imply that mc fail to run from the application menu.

All that imply the patch into the mc port is buggy because it should not change mc syntax depending on the in use shell.

 

[Dominique Michel]

Well, according to the port description, it must be some good reason to do that, and it recommend to use mc -u, or another user shell than sh. Which imply I will not argue with that choice, but I still consider that to use mc with sh should assume its -u option by default, that even when it is not explicitly given. Anyway, I used chrc to change my default shell and I will delete my hack and add a word into the fvwm-crystal doc about this.

 

[SirDice]

And worst, if in ~./.shrc, I add alias mc='env SHELL=/usr/local/bin/bash mc', it works when insinde urxvt or another terminal i run mc, but mc fail if I run urxvt -e mc, which in turn imply that mc fail to run from the application menu.

Note that ~/.shrc only gets executed if the ENV variable points to it. When you start urxvt -e {some command} that may not be the case, then ~/.shrc isn't sourced and anything you've set in there doesn't apply. The ENV variable is set in ~/.profile, and it is only executed if it's a login shell.

   Invocation
     If no arguments are present and if the standard input of the shell is
     connected to a terminal (or if the -i option is set), the shell is
     considered an interactive shell.  An interactive shell generally prompts
     before each command and handles programming and command errors
     differently (as described below).  When first starting, the shell
     inspects argument 0, and if it begins with a dash (‘-’), the shell is
     also considered a login shell.  This is normally done automatically by
     the system when the user first logs in.  A login shell first reads
     commands from the files /etc/profile and then .profile in a user's home
     directory, if they exist.  If the environment variable ENV is set on
     entry to a shell, or is set in the .profile of a login shell, the shell
     then subjects its value to parameter expansion and arithmetic expansion
     and reads commands from the named file.  Therefore, a user should place
     commands that are to be executed only at login time in the .profile file,
     and commands that are executed for every shell inside the ENV file.  The
     user can set the ENV variable to some file by placing the following line
     in the file .profile in the home directory, substituting for .shrc the
     filename desired:

           ENV=$HOME/.shrc; export ENV

     The first non-option argument specified on the command line will be
     treated as the name of a file from which to read commands (a shell
     script), and the remaining arguments are set as the positional parameters
     of the shell ($1, $2, etc.).  Otherwise, the shell reads commands from
     its standard input.

     Unlike older versions of sh the ENV script is only sourced on invocation
     of interactive shells.  This closes a well-known, and sometimes easily
     exploitable security hole related to poorly thought out ENV scripts.

 

[Dominique Michel]

Note that ~/.shrc only gets executed if the ENV variable points to it. When you start urxvt -e {some command} that may not be the case, then ~/.shrc isn't sourced and anything you've set in there doesn't apply. The ENV variable is set in ~/.profile, and it is only executed if it's a login shell.

I saw that. It is like in linux, but with the difference that linux use different .<shell>.profile files for sh and bash, when on freebsd, we have a common .profile file. csh is different and in fact, I try again, and fwm-crystal and mc works fine with it.

 

[SirDice]

It is like in linux, but with the difference that linux use different .<shell>.profile files for sh and bash

It'll be ~/.bash_profile and ~/.profile for bash(1). And it further depends on the distribution, on RedHat /bin/sh and /bin/bash are both bash (symlinked). On Debian /bin/sh is dash(1). Dash is similar to FreeBSD's sh(1) as they are both based on the Almquist Shell, with dash(1) being an enhanced and Debian specific implementation. dash(1) also points ENV to a slightly different file name; ~/.shinit.

 

[Deleted member 81054]

SHELL="/usr/local/bin/bash"
export SHELL

N.B. You can combine these into a single statement -- this saves "vertical space" so you can see more of the file on a screen:

export SHELL="/usr/local/bin/bash"

You should also be wary of using a shell that isn't always present on the root partition as problems mounting any other partition can leave you (and any scripts on which you rely) stuck without access to that executable.

And it further depends on the distribution,

Not forgetting that /etc/profile, login.conf and other assorted bits are also conditionally in the mix.

 

[Dominique Michel]

Not forgetting that /etc/profile, login.conf and other assorted bits are also conditionally in the mix.

Thanks,
The main issue for me is that urxvt -e <cmd> break some of the fvwm-crystal functionality with sh, and that including functions needed at its first statup.

I never used sh as a user shell before installing freebsd for the first time. I accepted most of the default settings and for the shell, it was a good choice because I was not aware at that time of freebsd separation of it base softare in / and other software in /usr/local, but succeeded to get a working system.