Hoping to not be offtopic

hansw

hansw

In the past I used a lot of aliases. It looks like there is no way to setup an alias while having /bin/sh as the env. So today I switched it to bash, it does work.
Is there any reason to not have aliases in /bin/sh? Or am I simply missing something?
 
According to sh(1) aliases should be applicable using sh, too. May be that is not really common because people use shells with more features rather than sh when aliases are useful.
 
Not a problem, just put this in your ~/.profile
Code: 
ENV=$HOME/.shrc; export ENV
and it will be sourced in every interactive shell you launch.
 
Figuring out how each different shell processes "dotfiles" is arcane, at best.

And bash(1) is definitely the most arcane of all.

For Bourne-like shells, setting ENV in your .profile and making sure that your window manager fires up a login shell every time you open a "terminal" will go a long way to resolving most issues. But it won't absolve you from reading the manual for your particular shell.
 
I put the alias(es) in .cshrc for tcsh (eg. root) and in .shrc for sh logins. The alias syntax is slightly different - sh wants an equal sign and ticks on the right-hand side.
 
I have been using zsh as it provides a lot of flexibility. ~/.zshenv and /usr/local/etc/zshenv are read for every invocation of zsh. ~/.zlogin is read for login shells. ~/.zshrc is read for interactive shells. ~/.zhistory is read for remembering history in an interactive zsh but commands in it are not executed. It has aliases, functions, command and file completion, command specific arg completion, history related commands, pushd/popd/dirs etc. etc. Any /bin/sh and most /bin/bash scripts should work in it unchanged.

pkg install it then read its man page(s)!
 
gpw928 said:
Figuring out how each different shell processes "dotfiles" is arcane, at best.

And bash(1) is definitely the most arcane of all.
Click to expand...

Create all the dotfiles and put this as the first line in each:
Code: 
[ -f ~/echodot] && echo .profile sourced # put the name of each file instead

Then, later, you can do `touch ~/echodot` and it will tell you which file is executed when you start shells.
 
cracauer@ said:
Create all the dotfiles and put this as the first line in each:
Code: 
[ -f ~/echodot] && echo .profile sourced # put the name of each file instead

Then, later, you can do `touch ~/echodot` and it will tell you which file is executed when you start shells.
Click to expand...
You can always do "ktrace -di <shell> ..." and then "kdump | grep NAMI" to see what files <shell> looks for.
 
bakul said:
You can always do "ktrace -di <shell> ..." and then "kdump | grep NAMI" to see what files <shell> looks for.
Click to expand...
Or just read the manual page.

Code: 
   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.

Most, if not all, shells have different behaviors when it comes to interactive vs. non-interactive and login vs. non-login.
 
SirDice said:
Most, if not all, shells have different behaviors when it comes to interactive vs. non-interactive and login vs. non-login.
Click to expand...
I don't think that interactive = login. At least with /bin/sh this is not true. When you switch to it by running sh from within /bin/csh or /usr/local/bin/bash it ignores ~/.profile and ~/.shrc.
 
Interactive is very much not the same as login.

You also have to consider cases like ssh sessions with fixed commands (not interactive, not having a tty). That is why I use the 'echodot' scheme above.
 
aragats said:
I don't think that interactive = login.
Click to expand...
Never said it was. I said there's a difference between interactive vs non-interactive AND login vs. non-login. You can have 4 different situations all behaving differently. Interactive non-login, interactive login, non-interactive non-login, and last but not least non-interactive login.
 
You must log in or register to reply here.
Back
Top