I wonder if there is a way to create a script as following :
#!/bin/ksh
export() {
echo "We're in the local function"
}
export
The main issue is that exportis an environment command for setting value of a variable or an environment variable, so when this script is run it will just prompt something like :
LOGIN=autosys
LOGNAME=autosys
MAIL=/usr/spool/mail/autosys
PWD=/home/autosys/wlp
SHELL=/usr/bin/ksh
TZ=Europe/Paris
HOME=/home/autosys
...
Obviously I could just name my function with a different name but as I am curious (and because this function should really be named export, logic purpose), I wonder if there is a way letting the script know I want to run the local export() function and not the environment command.
For example something like
export(){...}
call function(export)
Yes, export is a reserved word in shell. You will have to choose a different name.
Furthermore, you will have to source your shell script to apply any export to current shell instead of his son, forked.
If you really want to invoke something named “export”, use a shell file named “export”, for instance in /usr/local/bin:
/usr/local/bin/export bimbo lola juliet
Related
I read and verified that I can pass environment variables to node by doing something like:
MY_ENV_VAR1=/tmp MY_ENV_VAR2=/data node index.js
How on earth does that work? I've only seen arguments to a script come after the script name, not before.
Thanks!
That is the standard way of defining and passing on the environment variables to a particular command from a Linux shell w/o exporting it.
More details: https://unix.stackexchange.com/questions/158117/how-to-pass-environment-variables-to-a-non-interactive-shell-with-example
I've written a shell script, called credentials.sh, which contains:
export USERNAME = 'user'
export PASSWORD = 'pass'
Security of these variables is no big deal.
Two questions.
When I run this script, ./credentials.sh (both as root and not), it doesn't actually export the vars. Why is this?
What is the preferred way to do so they are universally available (Ubuntu 14.04)?
Two changes:
Fix your variable assignment syntax:
export USERNAME='user'
To make this value always available to user, append the above code line to the file ~/.profile; this will set the variables during login, such that this will not need to be manually invoked at other times.
I have been trying to write a script where instead of using names I have done the obvious and saved time by assigning user ids and placed them in a variable. var1=usid
echo $usid shows that its done correct but I save, exit and when I reopen in the morning, the variable no longer exists. Is there a way to make it permanent?
Why don't you use Unix export?
VAR=value
export VAR
The export command will mark each VAR for automatic export to the environment of subsequently executed commands i.e. make the local shell variable VAR global.
After installation of Ruby Version Manager (RVM) as root on an Ubuntu 14.04. I am confronted with a strange behaviour of bash. Let's have a look at the exported environment variables. I login as user ubunutu and run exportin my bash. Here are three of rvm's exported environment variables, others are available:
declare -ax chpwd_functions='([0]="__rvm_cd_functions_set" [1]="__rvm_after_cd")'
declare -x rvm_version="1.25.28 (stable)"
declare -x rvm_ruby_mode
Everything is pretty fine, but when I run bash -c export we get only:
declare -x rvm_version="1.25.28 (stable)"
Can someone explain me why all empty environment variables and all arrays are removed in the child bash? What must I do to ensure that really all environment variables of a parent shell are available within a child shell?
This problem is really a blocker for me. I am using vagrant and its shell provisioner. In one script I setup rvm and in a second one I must configure some gemsets. The problem is that in the second script the rvm commands do not run. The active shell only gets those environment variables of rvm with are non-arrays and non-empty. Manually sourcing of rvm.sh is no solution!
It is because as per last line of man bash:
Array variables may not (yet) be exported.
I read somewhere a note by BASH developer that it is because exporting an array is very complex and error prone.
Also this line:
declare -x rvm_ruby_mode
is only declaring a name of the variable with export attribute set (without value), if you assign it a value it will be available in the sub shell.
Here is post by BASH author on export of array in BASH.
A variable is created when a value is assigned to a name using the = operator, for example
foo=bar
creates a variable named foo with the value bar.
declare is used for two reasons: one, to allow dynamic creation of variables (which is beyond the scope of this question), and two, to set attributes on names (not necessarily variables). The command
declare -x rvm_ruby_mode
simply sets the export attribute of the name rvm_ruby_mode. To actually create a variable whose name has the export attribute set, you need to use the = operator, just as without the declare command.
declare -x rvm_ruby_mode=
Now rvm_ruby_mode is an empty variable whose named is marked for export.
I say "marked for export" because variables are not exported until a subshell is created. Until then, there is simply a list of names that, if the name has a value when a subshell/child process is created, are copied into the new environment. This list is separate from the list of actual variables (which again are names with associated values).
As to why arrays cannot be exported? The environment is technically not a set of variables, since a variable is a shell construct and the environment is something used by all processes in POSIX, whether or not run by a shell. The environment is simply a list of strings of the form <name>=<value>. There is no standard for how to pack the elements of an array into a single string which any process can parse and reconstruct into an appropriate data structure. While it's possible that bash could make an exception if it new the child process was another bash shell and come up with some way of embedding an array in the environment (like it does with function definitions), apparently this has not been done.
Now, I am writting a Groovy script to invoke other's interface. But I need change my current working path when running the script. I know it is not possible in Java. Is it possible in Groovy?
If you can run other script as separate process, you can give ProcessBuilder parameter working dir:
def processBuilder=new ProcessBuilder(command)
processBuilder.directory(new File("Working dir"))
def process = processBuilder.start()
or
command.execute(null, new File("Working dir"))
so that process will switch to your new folder and execute it there.
As Groovy runs on JVM, the same restrictions apply. Unfortunately it is not possible.
Changing the current working directory in Java?
JDK bug
Java/groovy doesn't really "Have" a working directory as far as I can tell. The shell that launched groovy has one and any child "commands" inherit from that shell diretly.
Java also seems to read the current directory of the shell and store it in "user.dir". This is used as a base for the "File" object so if you System.setProperty("user.dir", "c:/windows") it will change future invocations of new File(".") but will not change the parent shell directory (and therefore not the child directories).
Here are three "Work-Arounds" that may work for different scenarios:
1) I KIND OF overcame this for a very specific task... I wanted to implement "cd" as a groovy script. It was only possible because all my scripts were already being "wrapped" in a batch file. I made it so that my script could create a file called "afterburner.cmd" that, if it existed, would be executed when the script exits. There was some batch file trickery to make this work.
A startup cmd file could also "Set" the current directory before invoking your groovy script/app.
By the way, Having a startup cmd has been much more helpful than I'd thought it would be--It makes your environment constant and allows you to more easily deploy your "Scripts" to other machines. I even have mine compile my scripts to .classes because it turned out to be faster to compile a .groovy to a .class and start the .class with "Java" than it was to just run the script with "groovy"--and usually you can skip the compile step which makes it a LOT faster!
2) For a few small commands, you might write a method like this:
def currentDir = "C:\\"
def exec(command, dir = null) {
"cmd /c cd /d ${dir?:currentDir} && $command".execute().text
}
// Default dir is currentDir
assert exec("dir").endsWith("C:\\>")
// different dir for this command only
assert exec("dir", "c:\\users").endsWith("C:\\users")
// Change default dir
currentDir = "C:\\windows"
assert exec("dir").endsWith("C:\\windows")
it will be slower than "".execute() if "cmd" is not required.
3) Code a small class that maintains an "Open" command shell (I did this once, there is a bit of complexity), but the idea is:
def process="cmd".execute()
def in=process.in
def out=process.out
def err=process.err
Now "in" is an input stream that you could spin off/read from and "out" is an output stream that you can write commands to, keep an eye on "err" to detect errors.
The class should write a command to the output, read the input until the command has completed then return the output to the user.
The problem is detecting when the output of any given command is complete. In general you can detect a "C:..." prompt and assume that this means that the command has finished executing. You could also use a timeout. Both are pretty fallible. You can set that shell's prompt to something unique to make it much less fallible.
The advantage is that this shell can remain open for the entire life of your app and can significantly increase speed since you aren't repeatedly creating "cmd" shells. If you create a class (let's call it "CommandShell") that wraps your Process object then it should be really easy to use:
def cmd=new CommandShell()
println cmd.execute("cd /d c:\\")
println cmd.execute("dir") // Will be the dir of c:\
I wrote a groovy class like this once, it's a lot of experimenting and your instance can be trashed by commands like "exit" but it's possible.
you can wrap it up in a dir block.
eg :
dir('yourdirectory') {
codeblock
}