This combines the answer by Serge with an unrelated answer by David. It changes the directory, and then instead of forcing a bash shell, it launches the user's default shell. It however requires both getent and /etc/passwd to detect the default shell.
USER_SHELL=$(getent passwd <USER> | cut -d : -f 7)
In the first example:
The command line is evaluated, the value 'bar' is loaded into the environment variable 'FOO' and the python code is executed, which evaluates the environment variable 'FOO' and prints its contents: 'bar'
The second example: The command line is eavluated, the value 'bar' is loaded into the variable 'FOO' but echo $FOO is evaluated ...
You could switch to zsh instead of bash and use its s (for split) parameter expansion flag:
$ typeset -p words
typeset -a words=( foo bar '' baz )
Note that it's splitting not delimiting, foo,; would be split into foo and the empty string, not just foo like bash's IFS splitting would (with ...
IFS is a set of single-character separators, so with IFS=,;, either of ; or , would work as a separator, and a,b,;c;d would have five fields. If you want to use just the combination ,; as a single separator, you'll have to do it manually. One way is to replace that ,; pair with some single character you then do put in IFS:
Turns out that this was caused by Selinux policy preventing Crontab from writing to home directories. Similar case has been reported in Red Hat bugtracker:
Runing "crontab -e" with EDITOR=vim and do some changes to the cron
file. When quit from the vim, always gets a warning message: E138:
Can't write viminfo file /home/hpt/.viminfo! and some avc ...
With set -a (aka set -o allexport) bash exports all functions declared thereafter in addition to variables.
The error indicates that bash can't import a function called /users/avnamn/bin/pricer, not pricer.
Most likely before running source ./variables.sh, you had run (possibly in one of your startup files):
So when ...
if I want to use it in a second shell script I would have to export them instead, so the file would have to look like this:
You could source the second file, or have it source variables.sh. There are multiple ways to do what you wask, such as doing an eval over the result of processing the file, but the cleanest way would be to use set -a of bash shell:
What sudo -i does, is :
Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell.
That last point is important, shells read a number of startup files (depending on how exactly they're started, see e.g. Bash's manual ...
In Unix, the environment variables are not anything magical, they're simply a NULL-terminated array or pointers to strings (char **environ) which exists in the address space of the process, and which is explicitly passed as an argument to the execve(2) system call which is used to execute another program (1).
The execl(2) function which you're using is just ...
It's possible to use Bash's regular expressions to remove the path from the list.
while [[ $PATH = *:$dir_to_remove:* ]]; do
# Trim off ":" from the beginning and end.
The while loop technique will eliminate repeated entries too. I.e. When removing foo from a PATH ...
Yes, both bash and zsh (and dash and mksh and fish at least) set $PATH to a default value when not supplied in the environment they received on startup.
The POSIX shells that don't are still required to look up commands in a default search path.
Both bash and zsh (and some of the modules that are loaded automatically or not in the latter) set a number of ...
Any shell will use a "default" path (usually including at least /bin and /usr/bin) to lookup commands if the PATH envvar isn't defined. That behaviour is also replicated by execvp(2).
Some shells (like bash) will even set the PATH shell variable to their default path in that case.
What is the simplest way to start an interactive /bin/bash session ...
A possible workaround I'd like to share is somebody else is in the same situation as I am, is to use qdbus to send commands to another instance of konsole.
It's can be a bit convoluted because in my case I needed to know the Konsole's pid, but it did the trick.
Why completion doesn't always work
The exact effect of cdable_vars is that it allows cd foo as a shortcut for cd ~foo. Tilde expansion is what allows ~foo to stand for $foo when foo is a variable whose value starts with a slash.
The completion code for ~foo doesn't actually recognize parameters. You can reproduce the problem without the cd command: echo ~...
The _cd completer for the cd/pushd builtins will offer the named directories that have been added to the named directory hash table (see hash -d and the $nameddirs associative array).
Those are populated when you you reference those named dirs. Even if you run hash -df to build the named directory hash fully, it only adds the ~user entries (as documented).
If you use systemd-homed, you should be able to use homectl to set environment variables for your user account regardless of your shell.
The following command sets the EDITOR environment variable this way.
homectl update username --setenv=EDITOR=/usr/bin/vim
running tcsh after setContext sources all the initialization files again (~/.cshrc, etc..), which resets some of the variables set by setContext.
You could trick tcsh into not reading the ~/.cshrc by pointing the HOME environment variable to some other directory containing a .cshrc which resets HOME to its original value, sources the user's ~/.tcshrc or ~/....
A Linux program is executed using the execve system call. execve has the following signature:
int execve(const char *filename, char *const argv, char *const envp);
The last argument, envp, is used to pass the environment to the process, as an array of strings, each of the form key=value. By convention, the same environment is passed from one process to ...
Ssh only passes only the TERM environment variable through (+ LANG and LC_* in many default configs ^1). Changing the server's configuration to accept any environment variables can have serious consequences (allowing a user to bypass their login shell and any ForceCommand), and you should not do it.
Instead of trying to pass them through ssh, you could set ...
instead of setenv command, try export command
export myEnvVar="echo \"It works!\""
output: It works!
To make it permanent for your user:
in the .bashrc file (usually your your /home//folder)
add it at the last line, and reload the bash shell.
The PPID variable is a special shell variable (not an environment variable) that reflects the value of the parent process id. The value can be exported into the environment, but if it is passed to a subshell, the subshell creates a new PPID shell variable, and removes PPID from the list of variables to be exported to a subprocess.
The difference in behavior ...