"script" doesn't seem to fully recognize one's environment

rnturn · 12-08-2021, 11:56 AM

I'm working on a project that, sadly, involves software that seems to have been written by people who love typing long commands (and don't mind correcting the inevitable typos). As a result, some of us have created aliases to reduce the maddening amount of typing that's necessary to execute commands.

Now... as part of a request to "show me how to do this" I tried running a series of these long commands via their aliases and log the session using "script". Oops! "script" doesn't know about all of my environment. Well, by "my environment" I mean the normal collection of shell variables as well as the aliases. That seems to be too expansive of a definition as "script" is unaware that aliases have been defined. I've been using that utility for years (starting on big iron Unixen) and never noticed this before.

Is this normal "script" behavior? -- I see no switches that might help me out.

Is there a workaround? -- The only one that comes to mind is to bite the bullet and write a short shell script that uses the long version of the commands and run that during the "script" session. One other possibility is to source my ".profile" when first logging the session. (Works but sort of a pain.)

Mostly curious if anyone else has run into this and whether there's a clever fix.

TIA...

Hope everyone's set to enjoy the holidays.

shruggy · 12-08-2021, 12:17 PM

No, this is not normal. script inherits your environment including aliases (unless script itself was aliased to something else). Just tested with script from util-linux 2.23.2 (CentOS 7), 2.32.1 (CentOS 8), and 2.34 (Ubuntu 20.04 LTS).

rnturn · 12-08-2021, 10:55 PM

Quote:

Originally Posted by shruggy

No, this is not normal. script inherits your environment including aliases (unless script itself was aliased to something else).

Interesting. I'm running CentOS 8 via Oracle's VirtualBox and script is from util-linux 2.32.1. I'll have to look a tad deeper to see what's going on. May be time for strace though I'm unsure if I'd be able to interpret the results without having the script source code handy.

Thx for the reply.

pan64 · 12-09-2021, 04:01 AM

aliases are not inherited by default. see: shopt -s expand_aliases

shruggy · 12-09-2021, 05:07 AM

Hmm. Strange.

Code:

$ shopt|grep expand_aliases
expand_aliases 	on

But

Code:

$ grep expand_aliases .bash* /etc/bash*
.bash_history:shopt|grep expand_aliases

Looks like expand_aliases is enabled by default. From the GNU Bash manual:

Quote:

expand_aliases

If set, aliases are expanded as described below under Aliases. This option is enabled by default for interactive shells.

pan64 · 12-09-2021, 08:22 AM

for interactive shells, but for scripts executed by cron/ssh/whatever this option is not set (by default).

shruggy · 12-09-2021, 09:11 AM

script is supposed to be executed interactively.

pan64 · 12-10-2021, 12:29 AM

Quote:

Originally Posted by shruggy

script is supposed to be executed interactively.

You know, aliases are lost. So the mentioned shopt was not set. Actually I (we) don't know the real execution environment, therefore we could only guess, but I don't want to.

From the other hand better to use functions instead of aliases, that is more convenient (and should be exported too).

MadeInGermany · 12-11-2021, 10:10 AM

Neither functions nor aliases are environment, hence not inherited by child processes.

In bash functions (but not aliases) can be exported.
This is a trick though, working in few OS and requires coding/decoding to/from environment.

If you have defined your aliases in .bashrc then try to source it again after invoking script.