alias-commands not available in the Mutt-shell

[Michael Uplawski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Good morning, all.

The aliases that I have defined in .bashrc are not available in the Mutt
shell, after hitting '!'.

It certainly has to be that way, for a reason and I would not ask, if
it weren't so many on my system: Is there an alternative to turning each
alias into a shell-script or a macro (or both)?

TIA and happy new year, merry X-Mas and Easter. Take your time. Phosphate
runs out in 2030, only. ;-)

Michael
- --
GnuPG brainpoolP512r1/5C2A258D 2015-10-02 [expires: 2017-10-01]
sub brainpoolP512r1/53461AFA 2015-10-02 [expires: 2017-10-01]

-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQqRAnUVLTr0pDaCy3ouAYUXColjQUCWZAbxAAKCRDouAYUXCol
jWixAfkBS7fGof6hibqm1iJpmSd4i942Dm2eQ6iyv4dXzJNq+ik6Gr5n1lDqCZHQ
BfsVCQuRY2onHqfDAlbz/Mt0Mck3Af9mR9zI2DW5u+VpTbnIUsQFLwo4v8rfRrPe
g6cmZoCQqlNd3AVQR6Fz8QKV21Ac2pnNh8dtvTQ35CmZ98/dhXkg
=K+VY
-----END PGP SIGNATURE-----

[Ian Zimmerman]

On 2017-08-13 11:28, Michael Uplawski wrote:

> The aliases that I have defined in .bashrc are not available in the
> Mutt shell, after hitting '!'.

Since you mention .bashrc, I assume your /bin/sh is bash (you're not
running debian or ubuntu for example, both of which use dash).

So, define BASH_ENV environment variable to the filename of your
initialization script. See near the top of the bash manpage for how
this works.

--
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[Jorgen Grahn]

On Mon, 2017-08-14, Ian Zimmerman wrote:
> On 2017-08-13 11:28, Michael Uplawski wrote:
>
>> The aliases that I have defined in .bashrc are not available in the
>> Mutt shell, after hitting '!'.
>
> Since you mention .bashrc, I assume your /bin/sh is bash (you're not
> running debian or ubuntu for example, both of which use dash).

I use zsh myself on Debian, but I'm pretty sure it's common for users
to have bash as their default shell. dash(1) sounds more like a popular
choice for /bin/sh.

As for the OP's problem: ~/.bashrc is run by every /interactive/
shell. Do we know that Mutt's ! command starts an interactive shell?

If it doesn't, it may be hard to find a good place to activate
aliases, You don't want to burden every short-lived shell process in
scripts and pipelines with a lot of startup overhead ... and bash
doesn't even seem to support it.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Eike Rathke]

* Jorgen Grahn, 2017-08-14 09:11 UTC:

> On Mon, 2017-08-14, Ian Zimmerman wrote:
>> On 2017-08-13 11:28, Michael Uplawski wrote:

[fwiw, I didnt receive the OP, so I don't know if there was additional context]

>>> The aliases that I have defined in .bashrc are not available in the
>>> Mutt shell, after hitting '!'.
>>
>> Since you mention .bashrc, I assume your /bin/sh is bash (you're not
>> running debian or ubuntu for example, both of which use dash).
>
> I use zsh myself on Debian, but I'm pretty sure it's common for users
> to have bash as their default shell. dash(1) sounds more like a popular
> choice for /bin/sh.
>
> As for the OP's problem: ~/.bashrc is run by every /interactive/
> shell. Do we know that Mutt's ! command starts an interactive shell?

There are two cases:
1) entering a command (executable name and arguments) after mutt's
"Shell command:" prompt
* the executable is executed (via execle("/bin/sh","sh","-c",...)),
no interactive shell is started, hence aliases defined in ~/.bashrc
are not available, even if /bin/sh would point to bash (and then it
still would not behave as bash but mimic sh instead)
2) leaving the input field empty and hitting enter
* an interactive shell is started, if the SHELL env var is defined
then that is used as shell command, otherwise /bin/sh as
a fallback, and executed as in #1
* this should source ~/.bashrc if SHELL=/bin/bash (or whatever
applicable on that system)
* the shell has to be terminated with exit to return to mutt

> If it doesn't, it may be hard to find a good place to activate
> aliases, You don't want to burden every short-lived shell process in
> scripts and pipelines with a lot of startup overhead ... and bash
> doesn't even seem to support it.

Bash non-interactive looks for $BASH_ENV to source, but I doubt that's
also the case when invoked as sh, ie. if /bin/sh points to bash. If it
does then it would be possible to set BASH_ENV in the shell from which
mutt is started, though it wouldn't be a good idea to have
non-interactive shells source ~/.bashrc and/or arbitrary alias
definitions and what not..

Eike

--
OpenPGP/GnuPG encrypted mail preferred in all private communication.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Use LibreOffice! https://www.libreoffice.org/

[Michael Uplawski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thank you all for the reactions.

On 14 Aug 2017 22:01:21 GMT,

Eike Rathke <erack-nu...@posteo.de> wrote:
> * Jorgen Grahn, 2017-08-14 09:11 UTC:
>> On Mon, 2017-08-14, Ian Zimmerman wrote:

>>> Since you mention .bashrc, I assume your /bin/sh is bash (you're not
>>> running debian or ubuntu for example, both of which use dash).

I am running Debian but cannot imagine how any Linux-system could
restrict me to use one specific shell. Mine is bash.

>> As for the OP's problem: ~/.bashrc is run by every /interactive/
>> shell. Do we know that Mutt's ! command starts an interactive shell?

I understand this remark as a hint. But my research has been aiming at
the use of alias-commands, so far. The exact behavior of the ! command
is much better explained in your following statements, than in the docs,
I guess.

Okay, I will choose a few handy commands and handle them explicitly.

Cheerio,

Michael

- --
GnuPG brainpoolP512r1/5C2A258D 2015-10-02 [expires: 2017-10-01]
sub brainpoolP512r1/53461AFA 2015-10-02 [expires: 2017-10-01]

-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQqRAnUVLTr0pDaCy3ouAYUXColjQUCWZLFwQAKCRDouAYUXCol
jeMUAf4nVfM7LydYIusaciL73QzdOCMO6c0mNMpKyBVn4y38jO2iFtQyT0H6CUJn
O+SdQ6qbli0OCWU/gXavH/U9kIaKAf4nZsFcLMBJZrHe1P7pVGmNK6ADbmRh3Ta6
gutea5ZkZ14yJ7YHLj6UaIBZxLq6PTYWGujTRuzhN1zagB0SjoT+
=xkp9
-----END PGP SIGNATURE-----

[Ian Zimmerman]

On 2017-08-15 11:58, Michael Uplawski wrote:

> Okay, I will choose a few handy commands and handle them explicitly.

If you don't like having many small scripts around, you can write a
single script with multiple subcommands, in the style of "git fetch",
"git merge" etc.

[Jorgen Grahn]

On Tue, 2017-08-15, Michael Uplawski wrote:
>
> Thank you all for the reactions.
>
> On 14 Aug 2017 22:01:21 GMT,
> Eike Rathke <erack-nu...@posteo.de> wrote:
>> * Jorgen Grahn, 2017-08-14 09:11 UTC:
>>> On Mon, 2017-08-14, Ian Zimmerman wrote:
>
>>>> Since you mention .bashrc, I assume your /bin/sh is bash (you're not
>>>> running debian or ubuntu for example, both of which use dash).
>
> I am running Debian but cannot imagine how any Linux-system could
> restrict me to use one specific shell. Mine is bash.

I too argued against what he wrote, but I was a bit off. As I think
Eike Rathke pointed out, there are situations when "invoking the
shell" means running /bin/sh, rather than your configured luxury
shell. And then things vary depending on if /bin/sh is really dash,
bash, or something else.

>>> As for the OP's problem: ~/.bashrc is run by every /interactive/
>>> shell. Do we know that Mutt's ! command starts an interactive shell?
>
> I understand this remark as a hint. But my research has been aiming at
> the use of alias-commands, so far. The exact behavior of the ! command
> is much better explained in your following statements, than in the docs,
> I guess.

You're replying to what I wrote, but thosestatements you probably
refer to came from Eike Rathke, not me. And yes, they were
enlightening.

> Okay, I will choose a few handy commands and handle them explicitly.

I've felt for many years that shell aliases are kind of a trap, for
reasons like this one. They are not always there, and they aren't
inherited. I can imagine one getting used to them though, and I have
no good advice in that scenario.

[Michael Uplawski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Good morning. All, actually, but good morning Jorgen, too ;-)

I am sorry for a possible confusion with my recent post. It was supposed
to be convey a “somewhat final conclusion” and as such I did not address
each one of you individually in my responses.

On 15 Aug 2017 19:21:16 GMT,

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> I've felt for many years that shell aliases are kind of a trap, for
> reasons like this one. They are not always there, and they aren't
> inherited. I can imagine one getting used to them though, and I have
> no good advice in that scenario.

;-) The advice is all over the place.
With configurations becoming obsolete and distributions evolving, me,
too, I have made the experience of obsolete aliases that I had been so
accustomed to that their obsolesence was the last thing that I was
considering, when nothing worked anymore...

Anyway, it is just the amount of aliases that have accumulated, which
made me ask, I shall scrutinize them and extract something truely
useful, and useable.

Cheerio,

Michael


- --
GnuPG brainpoolP512r1/5C2A258D 2015-10-02 [expires: 2017-10-01]
sub brainpoolP512r1/53461AFA 2015-10-02 [expires: 2017-10-01]

-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQqRAnUVLTr0pDaCy3ouAYUXColjQUCWZQNmgAKCRDouAYUXCol
jTqdAfkBqAgUtVo9P9rW7ePIZRDYYHkDU22Fj/JaBht8w+LMxzLi/PN4JbyXS8dt
rAWlFvmr3g5F3Qm5QbdQ688wBUIyAf9oAW8Os3Ya7OABgaLD7TljXnzhUqFQzyRK
UzR/PSqC6fz4bCAMlJ/Nmo1DUO7cJgE3mKJGG5GsEwQylrZB4PLY
=HKLV
-----END PGP SIGNATURE-----

[Rich]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> If it doesn't, it may be hard to find a good place to activate
> aliases, You don't want to burden every short-lived shell process in
> scripts and pipelines with a lot of startup overhead

True.

> ... and bash doesn't even seem to support it.

Bash does support having non-interactive shells read configuration
files. One just has to be prepared ahead of time. From the Bash man
page:

When bash is started non-interactively, to run a shell script,
for example, it looks for the variable BASH_ENV in the
environment, expands its value if it appears there, and uses the
expanded value as the name of a file to read and execute. Bash
behaves as if the following command were executed:
if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
but the value of the PATH variable is not used to search for the
file name.

All the OP needs to do is export a BASH_ENV variable containing the
path to his alias definitions file just before launching mutt and then
the bash shells launched from inside mutt should read that file and
load his aliases.

[Rich]

Michael Uplawski <michael....@uplawski.eu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Good morning, all.
>
> The aliases that I have defined in .bashrc are not available in the Mutt
> shell, after hitting '!'.
>
> It certainly has to be that way, for a reason and I would not ask, if
> it weren't so many on my system:

No it does not have to be that way. For some reason your shell, when
launched from mutt, is not recognizing that it is running interactively
and loading the startup file.

From the Bash man page (by referencing .bashrc you imply that your
shell is Bash):

An interactive shell is one started without non-option
arguments and without the -c option whose standard input and
error are both connected to terminals (as determined by
isatty(3)), or one started with the -i option.

So it sounds like however you are connecting to this system, the
"isatty(3)" call is not returning "yes: tty" to Bash.

> Is there an alternative to turning each alias into a shell-script or
> a macro (or both)?

Add a "shell" config line to your muttrc telling mutt to launch bash
with the -i flag:

From the muttrc manpage:

shell
Type: path
Default: ""

Command to use when spawning a subshell. By default, the
user's login shell from /etc/passwd is used.

[Ian Zimmerman]

On 2017-08-16 10:02, Rich wrote:

> Add a "shell" config line to your muttrc telling mutt to launch bash
> with the -i flag:
>
> From the muttrc manpage:
>
> shell

The problem: (which you can only see if you inspect mutt source code, as
Jorgen & co. did but I, alas, did not)

If you change this setting, mutt will indeed change which shell it
_runs_; it will _not_ change the arguments passed to the shell,
including argv[0]. argv[0] is hardcoded to be "/bin/sh". So even if
you get mutt to run bash, bash will see it is run as sh and activate its
posixly-correct mode, dropping extra features such as BASH_ENV.

[Eike Rathke]

* Eike Rathke, 2017-08-14 22:01 UTC:

> 2) leaving the input field empty and hitting enter
> * an interactive shell is started, if the SHELL env var is defined
> then that is used as shell command, otherwise /bin/sh as
> a fallback, and executed as in #1

I got slightly carried away there, the shell used is the one determined
as login shell from /etc/passwd, which can be overridden by the muttrc
shell variable.

The $SHELL with /bin/sh fallback I mentioned is for the case that passwd
information could not be obtained.

[Eike Rathke]

* Ian Zimmerman, 2017-08-16 15:46 UTC:

> On 2017-08-16 10:02, Rich wrote:

>> Add a "shell" config line to your muttrc telling mutt to launch bash
>> with the -i flag:

> If you change this setting, mutt will indeed change which shell it
> _runs_; it will _not_ change the arguments passed to the shell,
> including argv[0]. argv[0] is hardcoded to be "/bin/sh".

You are mislead, mutt then runs

/bin/sh -c $shell

if no command was entered, but for a command still /bin/sh -c command

The
#define EXECSHELL "/bin/sh"
can only be changed during build time's
./configure --with-exec-shell=/bin/bash
for example.

[Eike Rathke]

* Rich, 2017-08-16 10:02 UTC:

> For some reason your shell, when
> launched from mutt, is not recognizing that it is running interactively
> and loading the startup file.

As I wrote in my post yesterday, if one enters a command at mutt's
"Shell command:" prompt, mutt does not run an interactive shell, it
effectively runs

/bin/sh -c command

If one does not enter a command, mutt uses the login shell (or shell
defined in muttrc) as command, so for example

/bin/sh -c /bin/bash

The bash shell instance then is an interactive shell.

> Add a "shell" config line to your muttrc telling mutt to launch bash
> with the -i flag:

> From the muttrc manpage:

> shell
> Type: path
> Default: ""

> Command to use when spawning a subshell. By default, the
> user's login shell from /etc/passwd is used.

That doesn't work because that shell value is used only as interactive
shell. Anyway, even if it wasn't, you can't pass command arguments when
bash -i is used, try

bash -i ls

which gives

bash: /bin/ls: cannot execute binary file

[Jorgen Grahn]

On Wed, 2017-08-16, Ian Zimmerman wrote:
...

> The problem: (which you can only see if you inspect mutt source code, as
> Jorgen & co. did but I, alas, did not)

Nitpick: I didn't read the source; Eike apparently did.

[Ian Zimmerman]

On 2017-08-16 19:08, Eike Rathke wrote:

> /bin/sh -c $shell
>
> if no command was entered, but for a command still /bin/sh -c command

You're right - the configurable shell setting only matters for an
interactive shell.

Why is that even needed today is another question :-) Who here uses
mutt on a real glass tty? In all other situations, you can just login
on a new virtual tty, or start another shell in one.

[Rich]

Ian Zimmerman <i...@primate.usenet-nospam-remove.net> wrote:
> On 2017-08-16 19:08, Eike Rathke wrote:
>
>> /bin/sh -c $shell
>>
>> if no command was entered, but for a command still /bin/sh -c
>> command
>
> You're right - the configurable shell setting only matters for an
> interactive shell.
>
> Why is that even needed today is another question :-) Who here uses
> mutt on a real glass tty? In all other situations, you can just
> login on a new virtual tty, or start another shell in one.

Or, run screen or tmux and just switch to another screen or tmux
'window'.

[Jorgen Grahn]

Or use job control (^Z) and put Mutt in the background while you're
using the shell.

I wasn't aware of the '!' Mutt command until the OP asked about it.
But it's a feature programs from the early 1990s tend to have; Nethack
has it, for example.