I simply want to source KSH with:
. ./.kshrc
within an expect script.
Is it possible to source KSH and run a KSH command within an expect script?
Sure, just launch a ksh interpreter to run it in:
exec ksh -c {. ./.kshrc; some_command}
Related
I am trying to run a single command using bash in a sh script. There is no way to use bash for the script, I have to use sh. However, I need to run a bash-only command in sh.
Basically, I want something like the following:
bash --command_in "echo foobar"
Is this possible? I don't want to make a second script file just to run that one command in bash (like bash my_script.bash).
Derp, it's the -c flag. This wasn't easy to Google, and the --help is prety brief.
When I need to run a bash script that runs cd somedir to affect the current shell I run it with . scriptname. However, if scriptname is a python script even with #!/usr/bin/env python3 in the first line, it doesn't work, it seems it expects the script to be a bash script. How can I make it work with python scripts (or any other language with the appropriate shebang)?
It is not possible.
The only thing that can affect current process environment is the process itself. Because the current shell is bash, the only thing that can be executed that could affect bash environment is something that can be run by bash itself. That "something" are statements interpreted by bash. Because bash doesn't support interpreting and running python statements, it is not possible.
The usual way around this, is to output from your python script properly escaped assignment statements that would assign environment variables. Then the output from your script is evalulated by bash. This is for example how eval "$(docker-machine ...)" works.
This question already has answers here:
Difference between sh and Bash
(11 answers)
Closed 5 years ago.
I have a file to be sourced in Centos 7.
It just works fine if I do :
$ source set_puregev_env
however, if I put this in a shell script, it doesn't work..
$ sh xRUN
xRUN: line 3: source: set_puregev_env: file not found
this is my shell script : xRUN
#!/bin/bash
source set_puregev_env
can anyone tell me what I might be doing wrong, or missing?
source is a command implemented in bash, but not in sh.
There are multiple ways to fix your script. Choose either one.
Run the script using bash interpreter
When you are invoking the xRUN script - you are explicitly telling it to be interpreted by sh
$ sh xRUN
To change and interpret the script with bash instead do
$ bash xRUN
This will make bash interpret the source command, and your script will work.
Use dot command to make script bourne compatible
You can also change the source with a dot command which does the same thing but is supported in both bourne and bash.
Change the line:
source set_puregev_env
With:
. set_puregev_env
Now the script will work with either sh or bash.
Make script executable
You should also run the script directly to avoid confusions like these by making it executable chmod +x xRUN, and invoking it like this:
$ ./xRUN
It will then use the command specified in the shebang and use the rest of the script as input. In your case it will use bash - since that is specified in the shebang.
I want to write a shell script to execute commands like "export JAVA_HOME=....."
How could I write a script?
I try:
#!/bin/sh
echo "test"
export PATH=$JAVA_HOME/bin:$PATH
export AWS_AUTO_SCALING_HOME=/usr/local/CLI
export PATH=$PATH:$AWS_AUTO_SCALING_HOME/bin
export AWS_CREDENTIAL_FILE=/usr/local/CLI/credential-file-path.template
But the commands are not executed.
But the commands are not executed.
They are executed, but in a sub-shell. The parent shell does not inherit these values.
Instead of executing your script, source it:
source /path/to/myscript.sh
Or
. /path/to/myscript.sh
Further reading: What is the difference between executing a bash script and sourcing a bash script?
How are you executing your script? If you use:
$ script.sh
the environment is set for the duration of the script, but the parent shell is completely unaffected by this (Unix is not DOS!).
To get the results of the commands into your shell, use:
$ . script.sh
or in Bash you can use:
$ source script.sh
(This is a synonym for the . (dot) command, which has been in shells since the Bourne shell. The source command was in C shell first, then added to Bash.)
These read the script into the current process. Any environment variable settings affect the current process. Your profile is effectively read using . $HOME/.profile, for example.
Note that the file for the dotted command is searched for in the directories on $PATH, but the file only needs to be readable, not executable too.
Have you tried setting permission to execute the file??
chmod +x filename
I can run Bash shell commands from with a Ruby program or irb using backticks (and %x(), system, etc). But that does not work with history for some reason.
For example:
jones$ irb --simple-prompt
>> `whoami`
=> "jones\n"
>> `history`
(irb):2: command not found: history
=> ""
From within a Ruby program it produces this error:
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31: command not found: history
In bash itself, those commands work fine
It's not that the Ruby call is invoking a new shell - it simply does not find that command...
Anyone know why? I'm stumped...
Most unix commands are implemented as executable files, and the backtick operator gives you the ability to execute these commands from within your script. However, some commands that are interpreted by bash are not executable files; they are features built-in to the bash command itself. history is one such command. The only way to execute this command is to first execute bash, then ask it to run that command.
You can use the command type to tell you the type of a particular command in order to know if you can exec it from a ruby (or python, perl, Tcl, etc script). For example:
$ type history
history is a shell builtin
$ type cat
cat is /bin/cat
You'll also find that you can't exec aliases defined in your .bashrc file either, since those aren't executable files either.
It helps to remember that exec'ing a command doesn't mean "run this shell command" but rather "run this executable file". If it's not an executable file, you can't exec it.
It's a built-in. In general, you can run built-ins by manually calling the shell:
`bash -c 'history'`
However, in this case, that will probably not be useful.
{~} ∴ which history
history: shell built-in command