I hope this isn't too simple a question.

How do you issue, in a script,

cd <path>/somedirectory

and have somedirectory continue as the working directory when you exit from the script?

Just source your script instead of executing it directly:or

(Sigh)

What does it mean, "to source my script?" I didn't know that "source" was a verb!

Let's say I have a script that contains,
cd ~/several/dirs/deep/petunia

The script is ~/bin/setpet and has the permissions 0755.
How can I arrange it such that issuing
setpet
while in the directory ~/notso/deep/do_it

returns, if I should subsequently issue
pwd
~/several/dirs/deep/petunia
?

Type either (mind the dot followed by a space):or:PS the syntax with the dot "." works in any POSIX compliant shell. The syntax with "source" only in some shells (e.g. in bash).

PPS In that case setpet doesn't even need to be executable.

Basically when you execute a script it runs in a separate shell with a separate environment. When the script finishes your back where you were when you started. To change the directory in the current environment you need to either source, use a function or via typed command. Sourcing a script is running those commands in the current shell.

http://www.linuxquestions.org/questi...script-926556/

michaelk wrote,
>Sourcing a script is running those commands in the current shell.

That's a head scratcher. All this time I've believed that _all_ commands are run in the current shell! Not so?

Hmm. Do you mean that by putting a period-space before the script name on the shell command line, the shell will run the script's commands without forking a different thread? That could be useful!

If you type in the command at the command prompt then yes. If you run a script that calls a command then no.

Depends on the command. Things like "echo", then the answer is yes.

If the command is "ls" then no. The ls utility gets anew process.
If it is a shell script, then USUALLY no. Only if the shell script is invoked by ". scriptname" (or an alias equivalent) will it be run in the same context.

"dot-space" does indeed let cd's in scripts carry over to the command line! Thank you very much.

A suggestion: How about the shell maintainers devising an environment variable that sets either way in stone -- along with an "undot-space" capability?

Thanks again!

hi wasup

Not possible. This isn't Windows (or VMS where it held logical names in a different name space).

To my suggestion the shell allow an environment variable that made all scripts run in the command line context, jpollard replied, "Not possible. This isn't Windows ..."

Just the fact that "this isn't Windows" is enough to make me reject a claim of impossibility. Call it the "SOURCE" variable and let the shell check whether it's enabled before executing the script. Should have the same result as invoking the script with dot-space.

Not everything is a shell script. Not everything uses the SAME shell or has the SAME syntax.

An executable shell script gets exactly the same environment as every other process. Don't want it? use the ". xxx" syntax or "source xxx" (depending on which shell you use...).

The difference is "context". Running within a single process is possible for multiple shell scripts. Unfortunately that also means you have only ONE global variable storage.

It is not possible to do for other executables. Those get a new context. Even if you use the "exec" you don't get the same environment variable context. You also get logged out if any of the scripts cause an exit...

Now you COULD sort of emulate it by writing your own command interpreter... then using "utilities" that are created as shared libraries. Then the interpreter could load/execute those utilities by using "dlopen" and associated functions. But it is cumbersome, slow, and error prone (any error/segfault within a library could cause the termination of your interpreter), it is also artifically made harder to debug.

jpollard wrote,
"Not everything is a shell script..."

Agreed. But please keep in mind my original request.

If the bash shell, when executing my script, which issues only one cd:
cd <path>/xyz
causes <path>/xyz to be the current working directory for the commands I type after the script returns, then the suggested environment variable works as requested. How it affects other contexts, if it does, is another issue. Side effects are not specified.

Actually, the "side effects" ARE specified.

ANY change in the context will affect the caller - and there is no way to undo it. Environment variables - path (which you usually don't want to change), working directory (which you do want to change), parameters, any variables used, traps,

What you end up with is one big context - and without a way to debug it.

The simple way this is protected is by processes. A process inherets a context, but does not export it. Thus when the process terminates, the parent process still has its context.

And without unexpected side effects. Any exit/abort - only terminates the process. It doesn't affect the parent.

The only element of the process returned to the parent is the exit status (which is how it detects that the process had an error). Without that - if the script exits... you are logged out.

That is why the "source" syntax works the way it does. It is very useful for initializing a context. But it is very poor at being an execution unit of its own.

For a rather complicated situation, consider the firefox utility. The /usr/bin/firefox command is actually a shell script. How would you like being logged out just because you closed the window? How would you like to try and work with such a script?

Just working with the bashrc initialization is tricky. Do it wrong and things like scp will not work. You can also be blocked from login.

That is why it is a case by case operation. Doing a "source" on every script would leave you with a nonfunctional environment.

1 members found this post helpful.