Hot answers tagged

13

The simplest solution is to just not use extensions for your scripts. They are not necessary and only serve to identify the script's type to you, but not to the computer. While Windows uses extensions to identify the file type, *nix systems (with very few exceptions such as gzip) do not. Note that binaries have no .exe extension in *nix, they're just ...


10

The variable is available in the main script, since you used . (the dot builtin, also known as source in some shells). . ./vars executes vars in the context of the calling script. Your problem is that you're using printenv to check, but printenv only prints environment variables, not shell variables. Environment variables are managed by the operating system ...


10

Sourcing your script only sets shell variables, while printenv shows environment variables. You will have to export the variables for printenv to show them. You may have meant to use set instead, which will show shell variables. You could have made this script: #!/bin/sh export MYVAR=MYVAL echo "EXECUTED!!" (given that you are using bash, the export ...


7

If you really want to do it, there is a way. Add the following at the end of .bashrc in your home directory, and set PATHEXT to extension names with dots separated by :. (Changed to include the dots to match the Windows behavior.) Use it at your own risk. if declare -f command_not_found_handle >/dev/null; then eval ...


6

short: no longer: shell scripts require a full filename, but you can define aliases for your commands to refer to them by various names. For example alias my-script=my-script.pl


5

Are there any historical reasons for there being two commands instead of one? There was just history manner. Bill Joy wrote the first version of printenv command in 1979 for BSD. UNIX System III introduced env command in 1980. GNU followed UNIX System's env in 1986. BSD followed GNU/UNIX System's env in 1988. MINIX followed BSD's printenv in 1988. ...


4

If your perl script produces no other output than the value of $circle, you can use command substitution to store that output in a variable. For example: circle=$(perl perlscript.pl) If the perl script produces other output as well (or not output at all), you'll have to either: extract only the value you want from the output using the usual text ...


3

$ declare -p > my_environment Later, inside barscript: . my_environment declare -p outputs environment variables in a form that can be executed by the shell, including quoting and escaping of variables as required. $ foobar='"some double-quoted text"' $ echo $foobar "some double-quoted text" $ declare -p foobar declare -- foobar="\"some ...


2

No, it's not the same. env VAR1="blahblah" command_to_run command_options runs command_to_run with VAR1="blahblah" in its environment; the containing shell's environment isn't affected. VAR1="blahblah" export VAR1 command_to_run adds VAR1="blahblah" to the shell's environment and makes it available for all subsequent commands, including command_to_run. ...


1

I'll try to answer all three parts of this question for you [Why is it] necessary to export LD_LIBRARY_PATH to ensure correct C# executable program behavior installation programs or scripts manage to find libc.so.6 in the subdirectory /usr/libx86_64-linux-gnu without requiring the customer specify an LD_LIBRARY_PATH Linked libraries are referenced ...


1

Normally, screen accepts a command and arguments, so this might work: screen -m -S 'test' nohup ~/<script-to-be-run>.sh Because it is not expecting a variable assignment, and the variable might otherwise be reset, you would probably have to add env to set the variable: screen -m -S 'test' env DISPLAY=:0 nohup ~/<script-to-be-run>.sh'


1

/etc/environment is a configuration file for pam_env, not a file read by a shell. The syntax is somewhat similar, but it is not the same. In particular, you can't refer to existing variables: you've set your search path to contain $ORACLE_HOME/bin and $PATH, i.e. directories with a dollar sign in their name. To set variables for all users, you can edit ...


1

The assignments in /etc/environment should be exported. Otherwise their values are not used. If you use "." to source a file, then you would use this syntax: export ORACLE_HOME=/usr/lib/oracle/12.1/client64 export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib But as noted, /etc/environment is not intended to be sourced (see for ...



Only top voted, non community-wiki answers of a minimum length are eligible