aeusesef@csun.UUCP (03/07/87)
[] Is there a way to pass parameters into aliases in Korn Shell? That is, in Berkely, I would use something on the order of '!*'; is there something equivalent for ksh? Any help is appreciated. Thanks, Sean Eric Fagan ----- Sean Fagan ------\ Computer Center litvax \ Cal State University, Northridge rdlvax \ 18111 Nordhoff St. psivax --> !csun!aeusesef Northridge, CA 91330 hplabs / AGTLSEF@CALSTATE.BITNET ihnp4 / ------/
guy%gorodish@Sun.COM (Guy Harris) (03/09/87)
>Is there a way to pass parameters into aliases in Korn Shell? That is, in >Berkely, I would use something on the order of '!*'; Berkeley isn't a huge city; I presume that if you can use that piece of C shell syntax within the city limits, you can use it outside the city limits as well. I think you meant "in the C shell"; not all systems that have the C shell are primarily derived from code in BSD distributions of UNIX, and not all people using systems so derived use the C shell. >is there something equivalent for ksh? The C shell uses aliases both to perform command aliasing and to provide "built-in" shell scripts. The Bourne and Korn shells use "shell functions" to do the latter.
aeusesef@csun.UUCP (03/10/87)
In a previous article, I write:
Is there a way to pass parameters into aliases in Korn Shell? That is, in
Berkely, I would use something on the order of '!*';
Is there something equivalent for ksh?
Later, Guy Harris (guy%%gorodish@Sun.COM) writes:
Berkeley isn't a huge city; I presume that if you can use that piece of C
shell syntax within the city limits, you can use it outside the city
limits as well.
All right, everybody makes mistakes. I just happen to have made my first
one in a posting (8-)).
I think you meant "in the C shell"; not all systems that have the C
shell are primarily derived from code in BSD distributions of UNIX,
and not all people using systems so derived use the C shell.
The C shell uses aliases both to perform command aliasing and to
provide "built-in" shell scripts. The Bourne and Korn shells use
"shell functions" to do the latter.
Yes, that is true. My problem is that I would like to alias cd, which Korn
shell will allow me to do. Apparantly, it looks through aliases first,
built-ins second, functions third, and PATH fourth. I tried making a
function called cd, but it didn't work, and an alias called cd did work, but
I was unable to pass parameters into it. Any one have any suggestions?
-----
Sean Fagan ------\
Computer Center litvax \
Cal State University, Northridge rdlvax \
18111 Nordhoff St. psivax --> !csun!aeusesef
Northridge, CA 91330 hplabs /
AGTLSEF@CALSTATE.BITNET ihnp4 /
------/
"I drank what?!" -- Socratesssl@ptsfa.UUCP (Sam Lok) (03/10/87)
In article <14672@sun.uucp> guy@sun.UUCP (Guy Harris) writes: >>Is there a way to pass parameters into aliases in Korn Shell? That is, in >>Berkely, I would use something on the order of '!*'; >>is there something equivalent for ksh? >The C shell uses aliases both to perform command aliasing and to >provide "built-in" shell scripts. The Bourne and Korn shells use >"shell functions" to do the latter. Ksh support both alias and function. To answer the original question, the answer is 'yes', try '$*' or '$@'. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sam Lok San Francisco {ihnp4,pyramid,qantel}!ptsfa!ssl || To err is human, to really foul things Disclaimer!? WHAT disclaimer? || up requires super-user privilege!
heiby@mcdchg.UUCP (03/11/87)
In article <580@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: >Yes, that is true. My problem is that I would like to alias cd, which Korn >shell will allow me to do. Apparantly, it looks through aliases first, >built-ins second, functions third, and PATH fourth. I tried making a >function called cd, but it didn't work, and an alias called cd did work, but >I was unable to pass parameters into it. Any one have any suggestions? The trick is to create a function with a different name, then alias "cd" to the name of that function. Here's part of what I do for "cd". I've omitted the code for the "resetps1" function. function ch { if cd ${*:-''} then resetps1 else return 1 fi } alias cd=ch # make it easy to use -- Ron Heiby, mcdchg!heiby Moderator: mod.newprod & mod.os.unix Motorola Microcomputer Division (MCD), Schaumburg, IL "Save your energy. Save yourselves. Avoid the planet 'cuae2' at all costs!"
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/15/87)
In article <580@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: >Yes, that is true. My problem is that I would like to alias cd, which Korn >shell will allow me to do. Apparantly, it looks through aliases first, >built-ins second, functions third, and PATH fourth. I tried making a >function called cd, but it didn't work, and an alias called cd did work, but >I was unable to pass parameters into it. Any one have any suggestions? I don't have much experience with ksh, but I have plenty with the SVR2 shell, which ksh is supposed to be almost entirely upward- compatible with. Indeed, the SVR2 shell provided no way to redefine builtins. We have fixed that in our version, with no apparent ill effects, and use the feature heavily (especially for "cd"). Along the way we added V8's "builtin" and "whatis" builtins. I don't have any patches for ksh, though.
dsp@ptsfa.UUCP (03/17/87)
In article <5680@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <580@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: >>I tried making a >>function called cd, but it didn't work, and an alias called cd did work, but >>I was unable to pass parameters into it. Any one have any suggestions? > >I don't have much experience with ksh, but I have plenty with the >SVR2 shell, which ksh is supposed to be almost entirely upward- >compatible with. Indeed, the SVR2 shell provided no way to >redefine builtins. We have fixed that in our version, with no >apparent ill effects, and use the feature heavily (especially for >"cd"). Along the way we added V8's "builtin" and "whatis" builtins. Here's part of my ENV file for ksh. I've honestly forgotten some of this. Order is important because the built-in is used in the function _cd and then the alias is applied later. Also a function to implement the V8 "whatis" - I guess it does because that's what the comment tells me :-) (I didn't write it) I have no idea what the "builtin" builtin does. And popd, pushd, dirs, probably thanks to someone on the net a few years ago. --------- _cd () { cd $1 > /dev/null; PS1="$PWD !> " ; } alias cd=_cd alias dirs='. $HOME/.functions;dirs' alias popd='. $HOME/.functions;popd' alias pushd='. $HOME/.functions;pushd' # whatis --- ksh function to implement the V8 whatis builtin function whatis { 'typeset' i_ foo_ # local variables 'typeset' -i var for i_ in $* do var=0 if 'set' | grep "^${i_}=" > /dev/null then 'set' | grep "^${i_}=" var=1 fi foo_="`'whence' -v ${i_}`" case "$foo_" in *built-in*) 'print' - builtin ${i_} ;; *function*) 'typeset' -f ${i_} ;; *exported*) 'print' - "alias -x '${i_}=${foo_##*alias for }" ;; *tracked*) 'print' - "alias -t '${i_}=${foo_##*alias for }'" ;; *alias*) 'print' - "alias '${i_}=${foo_##*alias for }'" ;; *not\ found) if ((! var)) then 'print' - "$foo_" fi ;; *) 'print' - "${foo_##*is }" ;; esac done return 0 } unalias pushd popd dirs swapdir # # The directory stack grows upward from 0. This is different from # the csh version where the top of the stack is always 0. # However, the direction of our stack is secretly reversed # when necessary to preserve the illusion of a stack with top # at 0. The idea is to make this program appear identical # to its counterpart in csh. # # invariant: dirstack[top] == $PWD # # From the csh man page... # # dirs # Prints the directory stack; the top of the stack is at # the left, the first directory in the stack being the # current directory. # # popd # popd +n # Pops the directory stack, returning to the new top # directory. With a argument `+n' discards the nth entry # in the stack. The elements of the directory stack are # numbered from 0 starting at the top. # # pushd # pushd name # pushd +n # With no arguments, pushd exchanges the top two elements # of the directory stack. Given a name argument, pushd # changes to the new directory (ala cd) and pushes the # old current working directory (as in csw) onto the # directory stack. With a numeric argument, rotates the # nth argument of the directory stack around to be the # top element and changes to it. The members of the # directory stack are numbered from the top starting at # 0. # let top=0 dirstack[top]=$PWD pushd () { dirstack[top]=$PWD # kludge to force . to top of stack case $# in 0) if (( top > 0 )) ; then let n=top-1 swapdir $n $top else echo No other directory. fi ;; 1) case $1 in +[1-9]*) n=$1 n=${n#+} if (( n > top )) ; then echo Directory stack not that deep. break else let n=top-n # "reverse" the stack swapdir $n $top fi unset n ;; *) if cd $1 ; then ((top=top+1)) dirstack[top]=$PWD dirs fi ;; esac ;; *) echo Too many arguments. ;; esac } popd () { dirstack[top]=$PWD # kludge to force . to top of stack case $# in 0) case $top in 0) echo Directory stack empty. ;; *) unset dirstack[top] let top=top-1 cd ${dirstack[top]} dirs ;; esac ;; 1) case $1 in +[1-9]*) n=$1 n=${n#+} if (( n > top )) ; then echo Directory stack not that deep. unset n break else let n=top-n # "reverse" the stack, and # shift the stack down one for all entries >= n while (( n < top )) do let m=n+1 dirstack[n]=${dirstack[m]} let n=n+1 done unset dirstack[top] m n let top=top-1 dirs fi ;; *) echo Bad directory. ;; esac ;; *) echo Too many arguments. ;; esac } dirs () { dirstack[top]=$PWD # kludge to force . to top of stack let n=top while (( n >= 0 )) do echo "${dirstack[n]} "\\c let n=n-1 done echo "" unset n } swapdir () { t=${dirstack[$1]} dirstack[$1]=${dirstack[$2]} dirstack[$2]=$t cd ${dirstack[top]} dirs unset t } -- David St. Pierre 415/823-6800 {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!dsp It looks like it's going to go on ad infinitum for a while.
twb@hoqax.UUCP (BEATTIE) (03/17/87)
> In article <580@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: > >I tried making a > >function called cd, but it didn't work, and an alias called cd did work, but > >I was unable to pass parameters into it. Any one have any suggestions? Make an alias which invokes the function. function CD { echo "cd func" } alias cd=CD Tom.
twb@hoqax.UUCP (BEATTIE) (03/17/87)
In article <2201@ptsfa.UUCP>, dsp@ptsfa.UUCP (David St.Pierre) writes: > Here's part of my ENV file for ksh. > <A bunch of very nice stuff removed> > > David St. Pierre 415/823-6800 {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!dsp Since this is in the ENV file doesn't it significantly increase the amount of time it takes to start a sub-shell. Why can't aliases and functions be exported like shell variables? Tom.
guy%gorodish@Sun.COM (Guy Harris) (03/18/87)
>Why can't aliases and functions be exported like shell variables?
The UNIX environment mechanism doesn't know about aliases and
functions. The low-level mechanism only knows about strings; the
user-mode code (in the shells, and in "getenv" and "putenv") knows
about strings of the form "<name>=<value>". You'd have to come up
with some convention to distinguish exported variables and aliases
from exported variables. You would not be able to have an equals
sign *anywhere* in the alias or function, because the "getenv" code
is very simple-minded and would see any string containing an equals
sign as a "<name>=<value>" item.
Also, since the environment is treated just like a second argument
list, it is subject to the same size limitations as argument lists.
This means, on most machines, no more than 5120 or 10240 or 20480
(depending on your flavor of UNIX) characters in your argument and
environment lists combined. My .kshrc is 4190 bytes; even if half
of them are comments, this is still a significant fraction of 5120.
If you get *really* fancy, you can push this limit - and remember,
this is a limit on the total size of environment variables *and*
arguments, so the bigger your environment gets, the smaller the
maximum number of arguments you can pass to a program gets.
It also takes time to copy a big environment when doing an "exec" -
and this time is spent on *every* "exec", regardless of whether it'll
use the values in the environment or not.dsp@ptsfa.UUCP (David St.Pierre) (03/18/87)
In article <730@hoqax.UUCP> twb@hoqax.UUCP (BEATTIE) writes: > >Since this is in the ENV file doesn't it significantly increase the >amount of time it takes to start a sub-shell. Doesn't really seem to. It may not have been apparent, but the dirs, popd, ... functions were actually defined in a separate file. An alias was defined which sourced then in at first reference and unaliased them. You bite it big the first time you use the functions, but after that it's pretty fast. > >Why can't aliases and functions be exported like shell variables? They can be - that's why they're in my ENV file! :-) Isn't this the sam question one asks of the .cshrc file? When I shell escape out of rn/vi/..., I like to have my aliases handy. >Tom. -- David St. Pierre 415/823-6800 {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!dsp If the onus fits, wear it.
m5d@bobkat.UUCP (Mike McNally ) (03/18/87)
In article <730@hoqax.UUCP> twb@hoqax.UUCP (BEATTIE) writes: > ... >Why can't aliases and functions be exported like shell variables? >Tom. Because the overhead on an execve (or whatever under SV) would be frightening. Most of the time, the target of the execve is not the shell. I suppose the shell could figure out when it should pass functions across the environment (does SV have something like the `#!interpreter' thing that BSD has?); this could be hard though. Doesn't the shell source some file each time it starts up? (Note -- I ask lots of these questions because of my almost pure BSD background. With the (*gag*) c shell and with (modestly) my shell, a file is sourced each time the shell is started; a different file is also sourced if the shell is the login shell. My shell has subroutines but does not attempt to pass them across execve boundaries.) -- Mike McNally, mercifully employed at Digital Lynx --- Where Plano Road the Mighty Flood of Forest Lane doth meet, And Garland fair, whose perfumed air flows soft about my feet... uucp: {texsun,killer,infotel}!pollux!bobkat!m5d (214) 238-7474
dce@mips.UUCP (David Elliott) (03/18/87)
In article <15224@sun.uucp> guy@sun.UUCP (Guy Harris) writes: >>Why can't aliases and functions be exported like shell variables? > >[ good points about problems of distinguishing aliases and functions > and about copying so much stuff ] One point that hasn't been mentioned is how shell scripts would be affected by having these items exported. I've seen a number of csh scripts whose first line is either # or #!/bin/csh This means that it could use my aliases (except that I don't set aliases for non-interactive shells), my paths, and other variables. At least csh has worked this way from the start, so people that don't write proper csh scripts get what they deserve. I wouldn't particularly like it if all of my shell scripts became broken just because aliases and functions all of a sudden got exported. -- David Elliott UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD: 408-720-1700
simon@its63b.ed.ac.uk (ECSC68 S Brown CS) (03/19/87)
In article <2204@ptsfa.UUCP> dsp@ptsfa.UUCP (David St.Pierre) writes: >In article <730@hoqax.UUCP> twb@hoqax.UUCP (BEATTIE) writes: >> >>Since this is in the ENV file doesn't it significantly increase the >>amount of time it takes to start a sub-shell. > >Doesn't really seem to. It may not have been apparent, but the dirs, popd, ... >functions were actually defined in a separate file. An alias was defined >which sourced then in at first reference and unaliased them. You bite it >big the first time you use the functions, but after that it's pretty fast. > In a version of the shell I've been hacking around, I've introduced a new keyword - "extern" - which defines an alias (or shell-function, or whatever) as existing in a library-file, but without explicitly giving it a value. When it is executed, it is recognized as being external and is automatically loaded in from the library file before executing it. So, the definition takes hardly any time at all (less characters to read, no parsing necessary), the first reference takes a while (search through a library file to find it - though hashed indexing could speed it up for very large libraries), and subsequent references can use the previously loaded-in alias value with no overhead at all at all. For example, "extern suspend" means that "suspend" is an external function (which implements job-control shell-suspension under systemV). (In fact, "extern -a" declares all the functions in a standard shell-library). This method allows lots of builtins to be taken out of the shell itself (if they were only there for efficiency reasons), and implemented as external functions instead. >> >>Why can't aliases and functions be exported like shell variables? > I do this by creating a variable called "ENV_FUNCTIONS" (or something like that) which has as its value a list of all functions that have been exported. Functions are exported with "export -f <function>". (Just "export -f" causes *all* functions to be exported). When a subshell starts up, it defines all the functions listed in this variable. For example, ENV_FUNCTIONS="extern suspend; extern pwd; hello(){ echo hi; }; ..." -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!{its63b,cstvax}!simon | Department of Computer Science | JANET: simon@uk.ac.ed.{its63b,cstvax} | University of Edinburgh, | ARPA: simon%{its63b,cstvax}.ed.ac.uk\ | Scotland, UK. | @cs.ucl.ac.uk ---------------------------------- "Life's like that, you know"
heiby@mcdchg.UUCP (Ron Heiby) (03/20/87)
In article <209@quacky.mips.UUCP> dce@quacky.UUCP (David Elliott) writes: |In article <15224@sun.uucp> guy@sun.UUCP (Guy Harris) writes: |>>Why can't aliases and functions be exported like shell variables? | |One point that hasn't been mentioned is how shell scripts would be |affected by having these items exported. Actually, they can be exported in ksh. They are then recognized by shell scripts. They are not known to Nth generation invokations, though. I.e. if you invoke ksh from within vi, you don't get them. By default, they are *not* exported, thus preserving compatible behaviour. -- Ron Heiby, mcdchg!heiby Moderator: mod.newprod & mod.os.unix Motorola Microcomputer Division (MCD), Schaumburg, IL "Save your energy. Save yourselves. Avoid the planet 'cuae2' at all nt wnt w
guy@gorodish.UUCP (03/20/87)
> Because the overhead on an execve (or whatever under SV) Just like other things that 4BSD and S5 both inherited from V7, it's "execve". > I suppose the shell could figure out when it should pass functions across > the environment (does SV have something like the `#!interpreter' thing that > BSD has?); No, although it *was* Dennis Ritchie's idea originally, so it's not as if it Wasn't Invented There.... Some vendors that started with S3/S5 code have added it. > Doesn't the shell source some file each time it starts up? Not the Bourne shell. The C shell will do so, and the Korn shell can be told to do so, but generally people set up their ".cshrc" or their Korn shell equivalent (it uses the file whose name is given by the ENV environment variable) so that it skips most of the setup glop used for interactive shells when it's running a script. Saves time - and, more importantly, saves aggravation; if you use private aliases, functions, or whatever in your scripts, you'd better either a) not give those scripts out or b) be prepared for lots of people asking you why the script doesn't work for them.
gwyn@brl-smoke.UUCP (03/20/87)
>>Why can't aliases and functions be exported like shell variables?
Actually, the 8th Edition UNIX shell supported functions in the
environment. I considered it when integrating shells into the BRL
Bourne shell, but decided it was neither necessary nor sufficient,
and it definitely breaks existing binaries that expect nothing but
NAME=VALUE format for environment entries.
An $ENV file (or equivalent per-interactive-shell startup file)
involves a similar amount of work as parsing the environment, so
it is acceptable for static global definition of shell things.
However, the environment would be better for dynamic things, if
its space weren't so limited.jerryp@tektools.UUCP (03/23/87)
In article <580@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: > ... I would like to alias cd, which Korn > shell will allow me to do. Apparantly, it looks through aliases first, > built-ins second, functions third, and PATH fourth. I tried making a > function called cd, but it didn't work, and an alias called cd did work, but > I was unable to pass parameters into it. Any one have any suggestions? I have an alias like this; it takes commandline parameters just fine: alias cd='. $HOME/.ksh/cd' # CHANGE DIRECTORY, RESET PROMPT Here's what's in the $HOME/.ksh/cd file: \cd $1 # \ MEANS USE REAL cd COMMAND, NOT ALIAS cdstat=$? # SAVE cd STATUS FOR cl ALIAS PS1="<`prompt ~ \`/bin/pwd\``,!> " # BUILT-IN pwd CAN'T HANDLE SYMLINKS set -- # CLEAR OUT POSITIONAL PARAMETERS FOR NEXT ALIAS (The "prompt" command is a prompt-generator.) --Jerry Peek, Tektronix, Inc. US Mail: MS 74-900, P.O. Box 500, Beaverton, OR 97077 uucp-style: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp Domain-style: jerryp@tektools.TEK.COM Phone: +1 503 627-1603
simon@its63b.UUCP (03/23/87)
In article <772@bobkat.UUCP> m5d@bobkat.UUCP (Mike McNally (Man Insane)) writes: >In article <730@hoqax.UUCP> twb@hoqax.UUCP (BEATTIE) writes: >> ... >>Why can't aliases and functions be exported like shell variables? >>Tom. > >Because the overhead on an execve (or whatever under SV) would be >frightening. Actually, I have not found this to be the case (under both SysV and BSD). Mind you, I only export a "few" functions (well, a few dozen, anyway...). Any difference in speed seems to be completely undetectable. >Most of the time, the target of the execve is not the >shell. I suppose the shell could figure out when it should pass >functions across the environment (does SV have something like the >`#!interpreter' thing that BSD has?). This is irrelevent. I want my functions to be exported to *everything* - not just immediate shells. After all, even if what I'm execle'ing now isn't a shell, it could very well spawn off a subshell itself at some future date (eg, doing a ":sh" in vi, or a "!" escape in lots of things). (BTW, SysV execve doesn't recognize #!, but the shell itself can when it tries to execute a commandfile). -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!{its63b,cstvax}!simon | Department of Computer Science | JANET: simon@uk.ac.ed.{its63b,cstvax} | University of Edinburgh, | ARPA: simon%{its63b,cstvax}.ed.ac.uk ... | Scotland, UK. | @cs.ucl.ac.uk ---------------------------------- "Life's like that, you know"
grs@houxa.UUCP (03/24/87)
In article <2295@tektools.TEK.COM>, jerryp@tektools.TEK.COM (Jerry Peek) writes: > In article <580@csun.UUCP> aeusesef@csun.UUCP (Sean Eric Fagan) writes: > > ... I would like to alias cd, which Korn > > shell will allow me to do. Apparantly, it looks through aliases first, > > built-ins second, functions third, and PATH fourth. I tried making a > > function called cd, but it didn't work, and an alias called cd did work, but > > I was unable to pass parameters into it. Any one have any suggestions? > > I have an alias like this; it takes commandline parameters just fine: > > alias cd='. $HOME/.ksh/cd' # CHANGE DIRECTORY, RESET PROMPT > > Here's what's in the $HOME/.ksh/cd file: > The preferred way to do this is to create a function which performs the change directory, and then alias cd to that function. For example: alias cd=chdir chdir() { cd $1 PS1="$PWD >" } or whatever. Glenn Sills BTL Merrimack Valley !houxa!grs
rwl@uvacs.UUCP (03/26/87)
> alias cd=chdir > chdir() > { > cd $1 > PS1="$PWD >" > } Actually, you have to quote the cd within chdir to retain it's orginal meaning. Otherwise you've set up a recursive call to the alias cd: alias cd=chdir function chdir { 'cd' $1 PS1="$PWD >" } I discover this while trying to modify cd to fit in with my pushd and popd functions. -- | Ray Lubinsky Department of Computer Science, University of Virginia | | INTERNET: rwl@uvacs.cs.virginia.edu | | CSNET: rwl%virginia@relay.cs.net | | UUCP: ...!cbosgd!uvacs!rwl |
lvc@danews.UUCP (03/31/87)
In article <350@houxa.UUCP>, grs@houxa.UUCP (G.SILLS) writes: > The preferred way to do this is to create a function which performs the > change directory, and then alias cd to that function. For example: > > alias cd=chdir > chdir() > { > cd $1 > PS1="$PWD >" > } > > > or whatever. > > Glenn Sills > BTL Merrimack Valley > !houxa!grs This is a somewhat better PS1/alias/function triple: PS1='$PWD >' # use single quotes alias cd=chdir chdir() { "cd" $* } The "s around the cd in chdir are *needed to prevent alias expansion* but still allows execution of cd. The $* is used instead of $1 because ksh cd can accept two arguments. The definition of PS1 can be done once in single quotes. It will be evaluated *every time* it is printed (so will the ENV parameter). -- Larry Cipriani, AT&T Network Systems, Columbus OH, (614) 860-4999
aeusesef@csun.UUCP (04/01/87)
In article <1341@uvacs.CS.VIRGINIA.EDU> rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) writes: $$ alias cd=chdir $$ chdir() $$ { $$ cd $1 $$ PS1="$PWD >" $$ } $ $Actually, you have to quote the cd within chdir to retain it's orginal meaning. $Otherwise you've set up a recursive call to the alias cd: $ $ alias cd=chdir $ function chdir $ { $ 'cd' $1 $ PS1="$PWD >" $ } $ $I discover this while trying to modify cd to fit in with my pushd and popd $functions. $ $-- $| Ray Lubinsky Department of Computer Science, University of Virginia | Ok, finally my reply (being the one who started this whole mess). The original problem was that I wanted to do something like this (this is for C shell): alias cd 'chdir !$ ; dirs' (please note that I did *not* want to change the prompt) in Korn shell. I tried alias cd='chdir !$ ; print - $PWD', but that didn't work, so I changed the !$ to $*. Still no go. That was when I posted my original article (got it somewhere around here...). Just after I posted it, it was suggested to me that I try alias cd=cd1 funtion cd1 { chdir $1; print - $PWD } That worked, but I wanted to see if there were any better way of doing it. So far, noone has suggested any. (Are you reading this, Bell Labs?) Anyway, that is the way to do it, and you cannot use the example above since chdir is a Korn shell built-in. Apparanlty, Korn shell searches aliases, then built-ins, then functions, then uses PATH. If, however, you use a different name, it will work. I tried to reply to everyone who sent me mail, but I am not sure if I did. To those whom I missed, and also those who posted replies, thanks for the try, its not your fault C shell is superior in only one aspect... ----- Sean Eric Fagan ------\ Computer Center litvax \ Cal State University, Northridge rdlvax \ 18111 Nordhoff St. psivax --> !csun!aeusesef Northridge, CA 91330 hplabs / AGTLSEF@CALSTATE.BITNET ihnp4 / ------/ "I drank what?!" -- Socrates | My opinions *are* facts.
dsuggs@hubcap.clemson.edu (darrell suggs) (08/04/90)
I need a copy of the KSH. We have the money and are willing to purchase it. My problem is that I have no idea where to look for it. Can anyone direct me to where to find out about it, or where to get it? Any help will be appreciated! Please email me at: dsuggs@hubcap.clemson.edu Thanks darrell suggs