Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Warning on alias' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Warning on alias
Authored by: Jordi Bunster on Aug 04, '04 11:11:54AM

It's because of their inclusion in FreeBSD 5 that Panther has them. They're not (as said) the GNU stuff, they just added -h.

I would NOT recommend aliasing the -h to the normal command, or aliasing any POSIX command to itself plus some switches, because scripts could easily rely on those acting according to POSIX. I'm not sure if the aliases also work for the scripts, but I imagine they would, unless one uses bash's features to differentiate interactive from non-interactive shell instances.

Of course, it depends on how much UNIX stuff you do, but it's always good to remember that.



[ Reply to This | # ]
Warning on alias
Authored by: geohar on Aug 05, '04 06:16:43AM

This is actually pretty common practice and won't cause recursion.

Shell scripts are interpreted by a separate shell invocation. For example, the sh-bang line will cause bash to be invoked in non-interactive sh compatibility mode (under os x earlier than 10.3 this was actually an invocation of zsh). At any rate, in this mode no initialization scripts are read - so no aliases occur.

As an example, create a simple file:

#!/bin/sh
ll

and chmod it to be executable. Normally ll is an alias to 'ls -l'. Type ll in the terminal to confirm this. Then execute the file. You should get 'command not found'.

To confirm -- script invocations run in a separate shell. whilst the environment bindings are inherited by that shell, aliases and the rest are not. Secondly, the bash invocation which runs the script will not read initialization files. This can often cause you to scratch your head if you include extra paths in the initialization file, run some commands that work interactively and then don't work in a script.

HTH



[ Reply to This | # ]