kapil@dartvax.UUCP (12/19/84)
*** REPLACE THIS LINE WITH YOUR MESSAGE *** I am facing a problem writing a command file. I would like this file to be run with an argument supplied. The command it executes is cd. the argument is the pathname it should default to. the command file enables the 25th line prints the new directory in reverse video, clears the screen and repositions the cursor at the top of the screen. I am attempting to pass the argument by -- cd $1 Is this the right way of doing it? I print the pwd in the command file and it prints the expected one. On using the command pwd outside the command file I find that the change in the directory has not been made. Why does it do this?
seifert@mako.UUCP (Snoopy) (12/21/84)
> I print the pwd in the command file and it prints the expected one. > On using the command pwd outside the command file I find that the > change in the directory has not been made. > Why does it do this? When you execute the command file, a child process is set up. The current directory *in the child process* is in fact getting changed, but this does not effect the current directory in the parent process. If you in fact want the command file to change the current directory in the parent process (normally your login shell), you have to get the shell to *not* set up a child process to execute the command file. This is done with the dot command. e.g.: $ pwd /usr $ . command_file include $ pwd /usr/include $ This also applies if you want to set shell variables from a command file. Just tried this, and $1 will get the argument if you don't use the dot command, but doesn't when you do. Very strange. Might be a Berkelyism, but I no longer have access to sys V to compare with. _____ |___| the Bavarian Beagle _|___|_ Snoopy \_____/ tektronix!tekecs!seifert <- NEW ADDRESS !!! \___/
Barry Gold <lcc.barry@UCLA-LOCUS.ARPA> (12/22/84)
Sorry for posting this; usual problem with munged return address. cd is a built-in command to the shell. It changes the current working directory of the shell's process. It MUST be built-in; if it were fork/exec'ed like normal commands it would change the working dir of only the child process. When you execute a command file, a new shell is created in a child process to interpret the commands. The cd command affects this child process's cwd, but leaves the parent process (YOUR shell), unaffected. That's why your command file behaves so strangely. If you use the c-shell, try something like: alias change "set x = \!\$; source changescript" Then change xx will cause the script to run in YOUR shell, not a child process, and the cd command will take effect as you desire. Of course, changescript must refer to $x instead of $1. barry
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/26/84)
The effect of "cd" cannot be exported outside the shell script to the invoker of the script. That is why "cd" is a shell built-in instead of an executable command in /bin.
colonel@gloria.UUCP (George Sicherman) (12/28/84)
[If it moves, eat it. --Vogon proverb] > I am attempting to pass the argument by -- > cd $1 > Is this the right way of doing it? > I print the pwd in the command file and it prints the expected one. > On using the command pwd outside the command file I find that the > change in the directory has not been made. > Why does it do this? Because a child cannot change its parent's environment. Maybe you should consider aliasing. -- Col. G. L. Sicherman ...seismo!rochester!rocksanne!rocksvax!sunybcs!gloria!colonel