Hi all.
I am trying to include the output of a command in a shell script (sh shell) but with no success.
Scenario is this: I have some XML and binary configuration files and I have an executable who writes a file with some shell variables I usually include in my shell script (executable "translates" configurations in shell variables).
At the beginning of scripts I put:
myexe > /tmp/config
. /tmp/config
(
/tmp/config containing something like:
IP="192.168.10.2"
SWITCH1="ON"
SWITCH2="OFF"
)
It will be good to use something like:
. $(myexe)
including directly the output of myexe executable instead of including an external file.
Do you know a way to accomplish this.
Thank you very much in advance.
TT:
Seems like this is the only way if you want to extract an environment which should be added to the environment of the currently running script. A command like
$(myexe)
will execute "myexe" in a subshell. (This is what "$(...)" means: execute what is inside the braces in a subshell.) If you change the environment in this subshell the changes will be lost once you exit it.
The only thing i suggest is to "chmod" the file "/tmp/config" before you run it. It has no execute rights from the start and even if this works it is counter-intuitive.
Thanks Bakunin!!!
I realize now I hid the real problem...
My question originated because when I execute:
myexe > /tmp/config
. /tmp/config
in concurrent scripts, sometimes, the second line is executed when someone other is writing /tmp/config, ending in an error.
Perhaps the simpler idea is to change script in :
First off, if you write to temporary files you should always prepare a place for these first and clean this place upon exit. Usually you can use the PID variable to make the places name unique, because the PID is always unique. I do it usually the following way (sketch only):
This way each instance of a script gets its own temp dir, puts everything it uses in there and upon exit (regardless which exit, even when terminated from outisde) it cleans up. The only way to have the temp files not cleaned is to terminate it with a "kill -9".
This is a great example of defensive programming, but the commands in trap 'commands' 0 will only be executed on a normal exit of the program. If the program is terminated by any signal (such as SIGINT or SIGQUIT which can easily be generated from the keyboard while a script is running interactively), the commands in this trap will not be executed.
If you wanted to perform the cleanup on exit and on termination by the signals SIGHUP, SIGINT, SIGQUIT, and SIGTERM you could use:
trap 'rm -rf "$TMPDIR" 1>/dev/null 2>/dev/null' EXIT HUP INT QUIT TERM
on systems that support the latest POSIX standard requirements. On UNIX branded systems, this would be equivalent to:
If you aren't using a UNIX branded implementation, the signal numbers listed above might not work on your system. The signal numbers used on your system should appear a file like /usr/include/signal.h or in some file it #include s. (There may be variant directories on your system corresponding to different versions of the standards and other ABI or API specifications your system supports.)
Understood, but as i sense that i am in for yet another piece of knowledge i missed until now, excuse the request for clarification:
I more or less (my real scripts are a bit more elaborated than the sketch shown here) followed the recommendations laid down here as my understanding was that "trap 0" in ksh is not a real signal but always executed at scripts end, regardless of how this ending came to pass - by signal, by simply end of program flow or by user interaction (pressing CTRL-C or something such).
The standards require that a trap action 0 (or trap action EXIT execute the specified action on exit, but never defines the term "exit" in this context. I had always interpreted "on exit" to mean when a shell script calls the exit special built-in utility or "falls off the end of the script"(which exits with the exit code provided by the last simple command executed by the script). But, at least bash and ksh behave as you expect.
Obviously, the commands specified by the action in a trap action EXIT command won't be executed if the shell is terminated by a SIGKILL signal since the shell can't catch a SIGKILL to invoke the actions specified by appropriate traps. If the standard is interpreted as you expect, then no system conforms to the standard because the standard doesn't allow an exception for being terminated by SIGKILL.
Thanks for pointing this out to me. I'll file a bug report against the POSIX standards and the Single UNIX Specification to try to get the next version of the standards to match existing practice in this area.
True. This notable exception i have explicitly stated (in post #4, last line). It is because of the nature of this signal, which is not directed at the process but rather at the kernel. A process terminated by SIGKILL doesn't terminate itself, but rather is terminated by the kernel.
Actually what i tried to get across was: save for SIGKILL, any other way of terminating a script (simple end, send a SIGTERM via "kill -15", press "CTRL-C", ...) will result in trap 0 (EXIT) being executed - not just using the "exit" built-in.
This is in fact as it should be because a script terminated by "kill -9" probably best leaves its temporary files for further inspection (one wouldn't terminate a script this way without some serious reason) and all other methods of ending a script are covered.