Aliasing cd to a function under ksh88
in [Shell]
|
From: Mark Hobley on 11 Feb 2010 03:08 Scott Bass <sas_l_739(a)yahoo.com.au> wrote: > Hmmm, I knew sh was installed, but I though sh=Bourne shell and > ksh=Korn shell and never the twain shall meet. Bizarre that /usr/bin/ > sh=Korn shell on HP-UX. Some systems use bash, which is another horror story. I try to use portable shell syntax here and test my scripts in hsh and ash. You might want to look at checkbashisms: ftp://markhobley.yi.org/devtools/checkbashisms/ (This does not detect everything anomaly between shells though, so I am always looking to improve this). Mark. -- Mark Hobley Linux User: #370818 http://markhobley.yi.org/
From: Jon LaBadie on 11 Feb 2010 04:46 Scott Bass wrote: > On Feb 11, 1:00 pm, Seebs <usenet-nos...(a)seebs.net> wrote: >>> PROMPT="$FG_GRAY$BG_RED$(logname)@$(hostname):\${PWD}$NC > " >>> PS1=$(print -n $PROMPT) >> Why are you setting this more than once? Why not just, in .profile: >> >> PS1="$FG_GRAY$BG_RED$(logname)@$(hostname)\${PWD}\$NC > " >> >> So far as I know, ksh expands variables in PS1 when printing it, so you >> don't have to touch PS1 when you cd. >> >> BTW, while we're talking about PS1: >> >> Put $? in PS1. I did this a few years back, and WOW has it been useful. >> It turns out that exit status is often very informative, and not always >> clearly displayed. > > Thanks Seebs, you're right. As I understand it: > > .profile is sourced by a login shell, i.e. interactive session > .kshrc is sourced by ksh, such as a ksh script (this includes an > interactive session) An "interactive" shell is not equivalent to a "login" shell. ~/.profile is intended to be processed by the first shell of a family of processes and should only need to be processed by that lead shell. Traditionally, in non-windowed, dial-in/telnet type connections this lead process would indeed be the login shell. In a windowed environment, often the shell started in a new terminal window is started as a login shell. Login shells are recorded in the wtmp log and thus show up in a who list. ~/.profile is used for setting things that may be needed by any process you run, but not for things like aliases which are used during interactive sessions. The file specified by $ENV (conventionally ~/.kshrc) is used for that. Things suitable for ~/.profile include your various path vars, eg. PATH, CDPATH, MAILPATH, FPATH, MANPATH, etc. Also, your preferred printer in LPDEST, and screen pager program (PAGER), options for various apps, like the LESS variable. Of course your ENV variable should be set to ~/.kshrc in here. And, if you need to do any terminal settings with stty, they should go in here as well. As mentioned, the second setup file, typically called .kshrc, should be used for setting things needed by interactive sessions, aliases, functions, PS vars, ... These items are not needed by scripts and in olden days fancy settings of $ENV were done to evaluate to "" if the shell were not interactive (option i not set). I believe recent versions of ksh93 skip $ENV (and thus .kshrc) processing if the i option is not set. Personally I don't count on this and surround my .kshrc code by a case statement case $- in *i*) <kshrc stuff> ;; esac. I also find that in some windowing environments I get interactive shells that are not forked from login shells, so ~/.profile has never been processed. To handle that situation I export a variable DOT_PROFILE_SEEN as "true" at the end of ~/.profile and test for it early in .kshrc. If missing, I source ~/.profile at that point. BTW in this thread I have several times seen PS1 being set without quotes or with double quotes. It really should be quoted with single quotes. PS1=$PWD PS1="$PWD" The above will not vary, but always include the path to the current directory at the time of assignment. PS1='$PWD' Now $PWD will not be evaluated until $PS1 is being printed.
From: Casper H.S. Dik on 11 Feb 2010 05:09 Seebs <usenet-nospam(a)seebs.net> writes: >On 2010-02-11, Janis Papanagnou <janis_papanagnou(a)hotmail.com> wrote: >> Quite common that there's another shell than Bourne shell behind 'sh'; >> on AIX it was a ksh as well (AFAIR), and on Linux systems it's a bash. >Except Debian/Ubuntu have switched to dash (a slightly tweaked ash). >Big performance win, apparently. It OpenSolaris it's ksh93 Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
From: Sven Mascheck on 11 Feb 2010 11:33 Casper H.S. Dik wrote: > Seebs writes: >> On 2010-02-11, Janis Papanagnou <janis_papanagnou(a)hotmail.com> wrote: >>> Scott Bass wrote: >>>> Are you aware of a document anywhere that lists the differences >>>> between Version 11/16/88 and Version M-11/16/88f? (I did check out >>>> your website - do I gain anything short of the listed bug fixes?) No, the RELEASEa file [1] apparently aims at fixes only, not new features. That's why I'm also interested in the changes [2], e.g., when was negation of a pipeline with ! introduced? (ksh88e/compile option?). Does anybody have access to detailed informations? >>> Quite common that there's another shell than Bourne shell behind 'sh'; >>> on AIX it was a ksh as well (AFAIR), and on Linux systems it's a bash. > >> Except Debian/Ubuntu have switched to dash (a slightly tweaked ash). I'd say rather heavily tweaked [3] > > It OpenSolaris it's ksh93 Let alone the very OS and shell releases... I'm aware that it's all media breaks, but that's exactly why I made the list what shells exactly are really out there (per "default"). -- [1] http://www.in-ulm.de/~mascheck/various/shells/ksh88-fixes [2] http://www.in-ulm.de/~mascheck/various/shells/ksh88-changes.html [3] http://www.in-ulm.de/~mascheck/various/ash/
From: Ivan Shmakov on 11 Feb 2010 12:07
>>>>> "S" == Seebs <usenet-nospam(a)seebs.net> writes: [...] S> BTW, while we're talking about PS1: S> Put $? in PS1. I did this a few years back, and WOW has it been S> useful. It turns out that exit status is often very informative, S> and not always clearly displayed. Well noted! I've found that I somewhat tend to use '&' just because it will display the exit code. And, well, — GNU time, for the same reason. -- FSF associate member #7257 |