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

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 ...


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 ...


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


3

You need to run export against the name of the variable. Right now, the variable is being referenced and replaced before export sees it. Change it to this: export user Note the lack of $ Your current version is essentially this: export ubuntu Because $user is interpreted first. You also lost your environmental variables when using sudo. There are ...


3

Traditionally, by login(1): ENVIRONMENT login sets the following environment variables: HOME The user's home directory, as specified by the password database. SHELL The user's shell, as specified by the password database. Though these days it might be a window manager or terminal program making those ...


2

sudo sanitizes environment before running any command, so unless you save the desired environment variable in /etc/sudoers using env_keep the varible will not be preserved by sudo. Alternately, for a single command, you can do: sudo LANG=en_US.UTF-8 some_command In order to preserve the current environment: sudo -E some_command


2

An environment variable is not meant to do such a trick. The script inherits the environment as a copy once it is run; the two environments are then independent. You may need to look for interprocess communication methods. If you really, really have to do this via variable, check this; although it's not the right way to communicate with a running process in ...


2

~/.xinitrc is only read when you start a GUI session with startx (or otherwise calling xinit) after logging in in text mode. So that won't help you. Whether ~/.bash_profile, ~/.profile, ~/.xprofile and ~/.xsessionrc are read when logging in with a display manager depends on how the display manager is configured and what session type you select when logging ...


1

Create a file like the following: #!/bin/sh USER=u PASSWORD=p IP=10.10.10.10 node app.js ... or ... #!/bin/sh USER=u; export USER PASSWORD=p; export PASSWORD IP=10.10.10.10; export IP node app.js ... where you put your own values in there instead of "u", "p", and "10.10.10.10". Save the file as, say, runapp, then make it executable with chmod u+x ...


1

Environment variables are specific to each process. When a process starts, it is given a copy of the environment (built up by the process which is starting it), and once it's started no other process can touch that copy. In your example, when you change the value of x, you're doing so in the shell you're running. By exporting variables, you tell the shell ...


1

Use exec bash at the end A bash script operates on its current environment or on that of its children, but never on its parent environment. However, this question often gets asked because one wants to be left at the bash prompt in a certain directory after the execution of a bash script from another directory. If this is the case, simply execute a ...


1

You can setup a pager to capture output and then quit if it fits on one screen. When it doesn't fit, you can use the pager to scroll and search. export PAGER=less export LESS=-FSXRi # -F and -X are relevant here, but that's what I use # also, less quickly toggles most by typing '-' and the option I imagine zsh has a way to automatically modify commands ...


1

whoami on Linux does not read the USER variable. On a "regular system" (meaning not using for example LDAP) it just does a geteuid(2) system call to get your current effective userid and then reads /etc/passwd to look up your username.


1

To understand this... does ExecStart depend on the environment set by this command? Because these lines are actually not executed in the same shell, so you can't expect them to share the environment. What you need is to use the Environment keyword in the unit file. That way, the ExecStart will get the environment defined by your file. ...


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 ...


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

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

On Linux: As root, iterate su <username> -c 'echo $VARNAME' --login over all relevant usernames. Should work in a similar way on HP-UX, but please check man su. It's important to use single quotes to prevent your local shell to expand the variable.


1

The list of files that bash loads during startup is documented in the manual. There's ~/.bash_profile, ~/.profile, ~/.bash_login and /etc/profile for a login shell, and ~/.bashrc (and /etc/bash.bashrc or similar on some systems) for an interactive shell. It's common for these files to include other files, and there's no general rule that would give you an ...



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