I have following environment variable OLD_KEY=value and want to rename the env var name so it is KEY=value.
Already tryied export KEY=${${OLD_KEY}}.
Anyone who has an idea?
Is a POSIX shell, like bash, you dereference a variable with a single dollar-sign. So this is all you need:
export KEY="$OLD_KEY"
The double-quotes are always a good idea, even if you don't think they're needed due to quirks of the POSIX shell standard. Specifically, how variable expansion interacts with $IFS.
P.S., You should have told us which shell (or language) you're using rather than make us guess.
Related
I'm trying to write a custom Travis env variable to a file for a simple proof of concept thing that I need. However, I'm having trouble getting this to work.
How would I define this in the travis yaml file if my variable is called VARIABLE_X ?
Thanks!
One way to do this is using linux commands, something like:
printenv | grep VARIABLE > all_env
However I don't know how Travis handles the environment (take a look at their docs, here) but it might not work as easily due to encryption, but it should work since your apps wouldn't function if they didn't have the same level of access. If such a case occurs, modifying a few parameters (maybe TRAVIS_SECURE_ENV_VARS) is worth looking into.
If you solved the problem in another way, consider sharing with the community.
Write the environment variable as usual (Shell - Write variable contents to a file)
Define the following within script:
- echo "$VARIABLE_X" > example.txt
I understand how you set an environment variable using elixir.
export AWS_ACCESS_KEY_ID=your_access_key_id
Okay that works, but what if I'm not confident that I typed everything correct and I want to check what the value is? How can I do this with Elixir?
You could leverage the following function: System.get_env/1.
It is my understanding that when invoking spawn "string command" in xmonad, the argument "string command" is actually passed to /bin/sh.
Is there a way to change this behavior ?
More specifically, is it possible to make the instance of the interpreter called by spawn aware of some predefined environment variables (typically, SSH_AUTH_SOCK and SSH_AGENT_PID)?
Of course, it is always possible to resort to spawn "$VARIABLE=stuff; export $VARIABLE; string command", but it bothers me that the variabe should be created and exported each time.
Strictly answering your first question, the safeSpawn function in XMonad.Util.Run (in xmonad-contrib) will run a command without passing it to a shell.
However, that shouldn't make much of a difference as far as environment variables are concerned. In both cases, the spawned command should inherit the environment of the XMonad process (which the shell's startup/rc files could tweak in the case of spawn).
It's possible to set the environment of the started process with general Haskell facilities, e.g. System.Posix.Process.executeFile (and System.Environment.getEnvironment if you want to make a modified copy of the XMonad process' environment).
I've been wondering, if there is an environment variable to set the search path for #use and #load for the ocaml toplevel.
What I think I know so far:
I can use findlib instead of "raw" #use and #load. findlib looks at some environment variables for the search path.
I can set a search path with -I.
Experiments seem to indicate that CAML_LD_LIBRARY_PATH does not influence #use (script loading) and #load (byte code file loading).
(updated) I can use #directory to add the desired path - but unfortunately this only takes a string literal, so i can't pass something I read from the environment at run time. (Update: I forgot to mention #directory originally and why it doesn't fit my use case).
What I want to do:
Run ocaml programs as scripts
Point ocaml to script libraries and script fragments with an environment variable
Avoid, in some scenarios, to create a full findlib library.
Presently I'm not using ocaml as interpreter, but a wrapper that adds a path to the invocation. I want to avoid the wrapper.
(I hope the questions makes sense now, after you know my use case)
So: Is there an environment variable to set the search path for #use and #load without resorting to a wrapper?
More Details
What I'm currently doing:
#!/usr/bin/env oscript2
#use "MyScript"
#load "SomeModule.cmo"
(* ... more ocaml *)
oscript2 is a wrapper around ocaml that basically sets the search paths for #use and #load, but finally executes the toplevel ocaml withe something like
exec ocaml -I .... ...some-byte-code-modules... "$#"
MyScript and SomeModule.cmo live outside of the "normal" Ocaml search path. The actual location might change, but after login (and working through the profie scripts) there is an environment variable (today it's OSCRIPTLOAD_PATH) that tells me, where alle loadable byte code and ocaml script files might live.
This works well, a variant of that setup has been in use for years (at least 7).
The one thing that bothers me there, is: The wrapper, the simple fact of it's presence, looks homebrew, so I'd like to avoid it, to make a better impression on potential future users of the script collection. What I'd like to do
#!/usr/bin/env ocaml
#use "MyScript"
#load "SomeModule.cmo"
(* ... more ocaml *)
and have ocaml itself pick up the search path from some environment variable (I'm free to change the variable name, that is under my control, but I don't want to install script and byte code libs into the default search path, and, as already stated, I' asking if I can do that without findlib).
Basically (as already stated at the very beginning) I'm looking for an environment variable that controls the search path for #use and #load. I'm not looking for toplevel directives and not for wrappers that retrofit this feature. (Thanks everyone for those suggestions, but unfortunately I've already gone that road, it's feasible, but here I'm looking for an alternative purely for cosmetic reasons).
Recent research didn't bring up that such a variable exists, but I thought I'd be asking here, before giving up on it.
From inside the OCaml toplevel you can use the #directory "foo";; primitive to add an include directory.
Here's a shell script that runs the OCaml toplevel while adding a directory to the search path taken from an environment variable named EXTRA_OCAML_DIR.
#!/bin/sh
ocaml -I "$EXTRA_OCAML_DIR" "$#"
If you run this instead of ocaml, you will have a directory in the load path specified by an environment variable.
It seems a little obvious, but maybe it will spark an idea that is more helpful.
In the Erlang shell i can re-use my variables very well. like this:
1> R = "muzaaya".
"muzaaya"
2> f(R).
ok
3> R = "muzaaya2".
"muzaaya2"
So, i cannot call f(Variable) in my source code because i do not know which module this function belongs to. I have tried modules like: erlang,shell,c, e.t.c. Has anyone tried re-using variables in Erlang Source code, other than just in the Shell ? How did you do it ? Thanks
No, you can't do this inside a module.
The REPL shell is interpreted, the code file is compiled.
The shell comes in handy to test things, but you would not write your web server in a shell. ;-)
It would be possible and not even difficult for the Erlang hackers to implement an f(V) language construct, but it would not fit the Erlang design model.
Mind, no function could accomplish the forgetting of a variable, so it had to be done in a new native language construct.
When compiled, the virtual machine does not know the variables anymore, as Erlang is run by a rather ordinary stack machine, not much different from the JVM.
It just would not be functional programming if one could rebind a variable V.
The functions which are listed when you type help(). in the shell are shell only functions and cannot be used when programming Erlang. f() is one of there functions.
As other have already pointed out f() is a shell command and only exists in the shell. That f(), and all other shell commands, looks like a normal function call is because the only way to do something in Erlang is to call a function. And the shell does not introduce any new syntax. All shell commands behave like normal functions in that they always return a value.
It was not deemed necessary to be able to use f() in normal functions, although there are many who disagree and find the once only binding of variables unnecessarily restrictive.