/etc/skel/.bashrc - lesspipe problem

[Hadmut Danisch]

Binary package hint: bash

Hi,

there's a bug in /etc/skel/.bashrc:

It calls the program lesspipe and evals it's output.

But the syntax of the environment commands that lesspipe spits out
depends on the SHELL environment variable.

Thus, if a user has a SHELL variable other than any sh dialect,
(e.g. tcsh), and runs bash, lesspipe issues csh-compatible commands
which are incompatible to sh. It fails to work and issues annoying
error messages.

replace

   eval "$(lesspipe)"

with

   eval "$(env SHELL=/bin/sh lesspipe)"

regards
Hadmut

[Dennis Kaarsemaker (dennis)]

Bash sets $SHELL -- if you set it to something else manuyally you'll
surely get more errors than this...

[Micah Cowan (micahcowan)]

Bash does set SHELL, but (1) only if it's not already set, and (2) always to the user's login shell, as specified in /etc/passwd (therefore, it's not always bash: if the user's login shell is /bin/tcsh, bash will actually set SHELL to /bin/tcsh).

The solution feels like a hack, but I'm not sure there's a better way to do this. We could make lesspipe check the environment for variables such as BASH or BASH_VERSION, but then if we get the reverse situation (invoking tcsh from a bash login), we might get the same problem (though we don't have a .tcshrc in /etc/skel to deal with, I suppose).

[Hadmut Danisch (hadmut)]

Micah Cowan wrote:
> Bash does set SHELL, but (1) only if it's not already set, and (2)
> always to the user's login shell, as specified in /etc/passwd
> (therefore, it's not always bash: if the user's login shell is
> /bin/tcsh, bash will actually set SHELL to /bin/tcsh).
>
> The solution feels like a hack, but I'm not sure there's a better way to
> do this. We could make lesspipe check the environment for variables such
> as BASH or BASH_VERSION, but then if we get the reverse situation
> (invoking tcsh from a bash login), we might get the same problem (though
> we don't have a .tcshrc in /etc/skel to deal with, I suppose).
>

The best solution would certainly be to modify lesspipe and lessfile.
They should have special options to override the env settings, e.g.
calling it as lesspipe -s or lesspipe -c , depending on whether you
are in a .profile or in a .tcshrc (actually you wouldn't call it in an
.cshrc, but a .login).

This would be a clean solution, but it would not be backwards compatible
to old versions of less. It would fail for users who did not upgrade the
less package.

regards
Hadmut

[Micah Cowan (micahcowan)]

Relying on any sort of environment variable seems problematic, and my suggestion especially will not work, because the division isn't between "bash and all other shells", but "csh and derivitaves vs all other shells."

Hadmut's solution or a similar one seems like the right direction to take on this, but it would require special handling to deal with /filename/ arguments passed to lesspipe when the filename itself is '-c' or somesuch (which is possible with, say "less -- -c").

I'd like to get this out of the Unconfirmed/Untriaged state at least, and seems to me the right thing to do would be Reject the bug for bash (as it's not really bash or bashrc's bug) and Confirm it for less. If it is later necessary for the .bashrc to be adjusted to the improvements for lesspipe, we can submit a new bug for that at that time.

If someone disagrees with me regarding bash, feel free to reopen the bug for it. If someone disagrees with me regarding less, I'd appreciate undertaking further discussion on it before Rejecting it.

[xteejx (xteejx-deactivatedaccount)]

As per the duplicate bug report bug 120459, this isn't a problem in Hardy upwards, but users upgrading to one of these will still have this problem.

[xteejx (xteejx-deactivatedaccount)]

Marking Triaged, there should be enough information here for a developer to begin working on this problem.