I'm using the stage command of sbt-native-packager to generate a start script for my application. The start-script template uses
#!/bin/bash
to find bash, but I'm on FreeBSD, thus my bash is in /usr/local/bin/bash. Is there a workaround for this that is any more convenient than invoking bash with the script filename as its argument, or editing the script each time it's regenerated?
The simplest way is to override template. Just put copy of original template with appropriate changes in src/templates. But notice that this feature available only in 0.7.0-M1.
Related
My original .bashrc script is currently used to run model runs. Now I need to manipulate it to compile a completely new model.
My question is, if I save my original .bashrc, as something such as .bwwbashrc, do I need to manipulate the file in some way so it is able to be read or recognized as the .bashrc when I source it within my scripts?
original sourcing
source /home/tsee/.bashrc
What I think the new sourcing would be.
(after creating .bwwbashrc)
source /home/tsee/.bwwbashrc
Just not sure if I need to save it with a certain extension or edit the executable in some sort of way.
Nope, you can name it whatever you want. Executable bit isn't required either.
If you aren't aware of it, the bash --login option might be of interest to you.
To complement Matt’s correct answer, I’d also point out that you can start a new Bash shell that sources your alternative file instead of .bashrc at start-up.
bash --rcfile .bwwbashrc
From the bash man page:
--rcfile file
Execute commands from file instead of the standard personal initialization
file ~/.bashrc if the shell is interactive (see INVOCATION below).
If you want to replace your current shell (with commands and settings from .bashrc), you can run
exec bash --rcfile .bwwbashrc
I have a utility function that I used a lot (assertReturnStatus()). I'd like to define it in a utility file (utility.sh) and reuse it in other bash scripts.
How can reuse the function from another bash script file? Thanks.
You need to "import" the first file in the second.
Be warned that this will litterally include the first, so any code in the first will be executed as if it were litterally in the place of the line.
The syntax is:
# if /path/to/file exists, then include it
[ -f /path/to/file ] && . /path/to/file
Note bash also support the keyword source (ie: source /path/to/file) but it is not POSIX compliant and might not work in other shell like ash, dash, posh.
If you don't want to do an explicit sourcing of your script file as bufh suggests: I put my often used functions in my .bashrc which gets always sourced thus having the functions always available.
As bufh pointed out in a comment always is not really always but limited to interactive shells. So, if you're planning to use the scripts from an interactive session, you could put it into the .bashrc, otherwise go for explicit sourcing.
I'm writing a small script to manage my installed JDK on a linux machine, say for example that the name of the script/function is usejdk.
I come with to ways :
usejdk is a bash function in shell script sourced the file in .bashrc or .bash_profile.
use usejdk as the name of the shell script and add it to the ~/bindirectory which is the PATH.
What is the idiomatic way to deploy a shell script on a unix machine between the two ?
If you are creating something for other people to use, a self-contained script they can put in their PATH and replace with new versions as needed is far easier, better, and maintainable than a function that will require them editing their startup files.
I (on mac osx) often use
export http_proxy=http://192.168.0.205:1099
to proxy http connection to get a highed download speed. To make things easy， I wrote a shell file named proxy.sh to do this:
#!/bin/sh
export http_proxy=http://192.168.0.205:1099
Before I downlaod, I execute proxy.sh shell command, but I found it did't not come into effect.It lost http_proxy variable in current commnad window(terminal). I must type export command in current terminal,it will come into effect.
So I want to know what's reason for this and a solution? thanks.
Running a shell script "normally" (with proxy.sh for example) results in that running in a sub-process so that it cannot affect the environment of the parent process.
Using . or source will run the shell script in the context of the current shell, so it will be able to affect the environment, using one of the following:
. proxy.sh
source proxy.sh
Another possibility (if you're using bash at least) is to create an alias to do the work for you. You can use something like:
alias faster='export http_proxy=http://192.168.0.205:1099'
so that you can then simply type faster on the command line and it will export that variable (in the context of the current shell).
You could also allow for one-shot settings such as:
alias faster='http_proxy=http://192.168.0.205:1099'
and then use:
faster your_program
which would translate into:
http_proxy=http://192.168.0.205:1099 your_program
That's a bash way to set a variable for just the one invocation of a command.
The export variable will only apply to the script -- if you want it to apply to the shell, you need to use source, and execute the script like so:
. ./proxy.sh
or:
source ./proxy.sh
Note the "." in the first example -- the dot follow by space means the script will apply to the shell.
The reason why your script does not work has been explained by Drakosha & how to make your script work has been explained by Anothony. But with the export in the script you need to source your script each time you open a new terminal. A better solution will be to add the export in .bash_profile or .bashrc
Hope this helps!
When executing a shell script a new shell is launched, the script is executed, and the shell dies. That's why you don't see the variable defined in your shell.
I suggest using an alias for the same purpose.
I have a script whose content simply exports a variable in linux.
export LD_LIBRARY_PATH=....
I want to run this script in my Perl script so whoever is running my Perl script will have their LD_LIBRARY_PATH set. Can i just do this in the beginning of my Perl script:
#!/usr/bin/perl -w
system(". /myfolder1/myfolder2/myScript.sh");
#!/bin/sh
. /myfolder1/myfolder2/myScript.sh
exec perl -wxS "$0" "$#"
#!/usr/bin/perl -w
# .. the rest of your script as normal
When you run this, it will first be executed by /bin/sh, which is capable of loading myScript.sh into the local environment. sh then execs Perl, which is told to continue from the following line.
This won't work. To change the environment inside your Perl script (and to change the environment that will be passed on to commands run from inside your Perl script), change the %ENV variable.
$ENV{"LD_LIBRARY_PATH"} = ... ;
This won't work. There is no way for a subshell to manipulate the environment of the parent process.
But you could make your script echo the string you want to set as LD_LIBRARY_PATH and then from within your Perl script you could do something like that:
$ENV{LD_LIBRARY_PATH} = `path/to/your/script.sh`;
Of course, a bit of error checking might also be a good idea.
No. Your environment changes made in a child cannot affect the parent. This means running a script will not affect perl. Also perl will not affect the shell from which it was called. You can edit the environment inside perl by changing the special variable %ENV. If there's some kind of unreproducible calculation done in that script, maybe the script should just echo the setting and perl can pick that up on STDOUT and use it.
I {changed directory, modified my environment} in a perl script. How come the change disappeared when I exited the script? How do I get my changes to be visible?
Unix In the strictest sense, it can't be done -- the script executes
as a different process from the shell
it was started from. Changes to a
process are not reflected in its
parent, only in its own children
created after the change.
I had a similar problem a few years ago and whipped up a little module, Env::Sourced, that should do the trick.
use Env::Sourced qw(/myfolder1/myfolder2/myScript.sh);
...
Another option (other than making the changes directly in Perl's %ENV) is to make the changes you want a Perl module, so that you can say:
use MyEnvironment;
and have it modify your environment in all your scripts. It would make it simple to make changes after the fact that will not require editing every script.
The module itself will be simple, something like this:
package MyEnvironment;
$ENV{LD_LIBRARY_PATH} .= ":/some/path/you/want/appended";
# Any other changes you want here.
1;
That won't work. An (unpleasant) alternative might be to replace /usr/bin/perl with a shell script that first executes your script and then executes the perl executable.
This can't be done in the way you're trying to do this.
It either needs a wrapper shell script that sets LD_LIBRARY_PATH and then calls your perl script, or any user executing the script needs to have LD_LIBRARY_PATH set correctly in the first place.
If doing the latter, then this can be managed globally by editing /etc/profile and /etc/cshrc (for ksh, sh, bash, csh and tcsh) shells. You can then test for the value of LD_LIBRARY_PATH in your script and if not set/set incorrectly then print a friendly message to the user. Alternatively individual users can set this in their local .profile/.cshrc files.
Note: you haven't given any information about the environment or useres that might run this, so there's also the possibility that users may set LD_LIBRARY_PATH to something they need. If you do check LD_LIBRARY_PATH for a "good" value in your script, then keep in mind that several paths may have been specified, so you will need to parse this environment variable properly.
If you can find the right place in your perl script, this works as in my example:
$ENV{"LD_LIBRARY_PATH"} = "/oracle/product/10g/lib";
And it didn't require me to call another script to set the env var.
The Env::Modify module addresses this issue, at least for POSIX-y platforms:
use Env::Modify 'source';
source("/myfolder1/myfolder2/myScript.sh");
... environment settings from myScript.sh are now available to Perl ...