Tag Info

26

The EDITOR editor should be able to work without use of "advanced" terminal functionality (like old ed or ex mode of vi). It was used on teletype terminals. A VISUAL editor could be a full screen editor as vi or emacs. E.g. if you invoke an editor through bash (using C-x C-e), bash will try first VISUAL editor and then, if VISUAL fails (because terminal ...

26

PATH=$PATH:~/opt/bin PATH=~/opt/bin:$PATH depending on whether you want to add ~/opt/bin at the end or at the beginning. You don't need export if the variable is already exported: any change of the value of the variable is reflected in the environment. (This wasn't true in older shells, but you're highly unlikely to encounter such old shells these days.) ...

19

The trap is that IFS=; while read.. sets the IFS for the whole shell environment outside the loop, whereas while IFS= read redefines it only for the read invocation. You can check that doing a loop like while IFS= read xxx; ... done then after such loop, echo "blabalbla $IFS ooooooo" prints blabalbla ooooooo whereas after IFS=; read xxx; ... ... 18 VAR=$VAR1 is a simplified version of VAR=${VAR1}. There are things the second can do that the first cant, for instance reference an array index (not portable) or remove a substring (POSIX-portable). See the More on variables section of the Bash Guide for Beginners and Parameter Expansion in the POSIX spec. Using quotes around a variable as in rm -- "$VAR1" ...

17

The shebang expects a full path to the interpreter to use so the following syntax would be incorrect: #!python Setting a full path like this would work: #!/usr/local/bin/python but would be non portable as python might be installed in /bin or /opt/python/bin or wherever location. Using env #!/usr/bin/env python is a method allowing a portable way ...

16

${VAR} and$VAR are exactly equivalent. For a plain variable expansion, the only reason to use ${VAR} is when parsing would otherwise grab too many characters into the variable name, as in${VAR1}_$VAR2 (which without braces would be equivalent to${VAR1_}$VAR2). Most adorned expansions (${VAR:=default}, ${VAR#prefix}, …) require braces. In a variable ... 16 The shebang line (from “sharp bang”, i.e. #!) is processed by the kernel. The kernel doesn't want to know about environment variables such as PATH. So the name on the shebang line must be an absolute path to an executable. You can also specify an additional argument to pass to that executable before the script name (with system-dependent restrictions I won't ... 16 You have to put the declaration in the initialization files of your shell: If you are using bash, ash, ksh or some other Bourne-style shell, you can add export ABC="123" in your .profile file (${HOME}/.profile). This is the default situation on most unix installations, and in particular on Debian. If your login shell is bash, you can use .bash_profile ...

16

It is an expected behavior, and already discussed several times. The script is run in a subshell, and cannot change the parent shell working directory. Its effects are lost when it finishes. To change directory permanently you should source the script, as in . ./script

15

It's going to list all of the non-loopback IP addresses on the system. Assuming you only have one non-loopback IP address on this box, it's going to export the IP address of the system to the environment variable "IP". Start by running the pipeline one "section" at a time. Meaning, first run /sbin/ifconfig to see what it does. Then run ... ...

15

Either way works, but they don't do the same thing: the elements of PATHare checked left to right. In your first example, executables in ~/opt/bin will have precedence over those installed, for example, in /usr/bin, which may or may not be what you want. In particular, from a safety point of view, it is dangerous to add paths to the front, because if ...

14

The file $HOME/.profile is used by a number of shells, including bash, sh, dash, and possibly others. From the bash man page: When bash is invoked as an interactive login shell, ... it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ... 14 Exported variables are carried into the environment of processes started by the shell that exported them, while non-exported variables are local to the current process only. From the export man page: The shell shall give the export attribute to the variables corresponding to the specified names, which shall cause them to be in the environment of ... 14 You can do this with env: env -i your_program Contrary to comments below, this does completely clear out the environment, but it does not prevent your_command setting new variables. In particular, running a shell will cause the /etc/profile to run, and the shell may have some built in settings also. You can check this with: env -i env I.e. wipe the ... 12 Let's look at an example, with some carefully-crafted input text: text=$(cat <<'EOF') hello world\ foo\bar EOF That's two lines, the first beginning with a space and ending with a backslash. First, let's look at what happens without any precautions around read (but using printf '%s\n' "$text" to carefully print$text without any risk of ...

11

Here is a solution, inspired by the previous answers: $comm -3 <(declare | sort) <(declare -f | sort) breakdown: declare prints every defined variable (exported or not) and function. declare -f prints only functions. comm -3 will remove all lines common to both. In effect this will remove the functions, leaving only the variables. To only print ... 11 The traditional Bourne shell didn't support combining them (although the System V one let you omit the ;; the 4.2BSD / SunOS shell didn't). It was added by the Korn shell (crossing the Bourne shell's export with csh's setenv) and subsequently adopted by other shells and by POSIX.2. Many commercial Unixes still ship the System V variant of the Bourne shell ... 11 Shell variables vs. environment variables MY_HOME="/home/my_user" sets the shell variable called MY_HOME. Shells are programming languages, and have variables (also called parameters). After this assignment, you can use the value of the variable, e.g. with echo "$MY_HOME". Shell variables are an internal shell concept. When that shell instance terminates, ...

11

The problem is service strips all environment variables but TERM, PATH and LANG which is a good thing. If you are executing the script directly nothing removes the environment variables so everything works. You don't want to rely on external environment variables because at startup the environment variable probably isn't present and your init system ...

10

For security reasons, sudo may clear environment variables which is why it is probably not picking up $JAVA_HOME. Look in your /etc/sudoers file for env_reset. From man sudoers: env_reset If set, sudo will reset the environment to only contain the following variables: HOME, LOGNAME, PATH, SHELL, TERM, and USER (in addi- tion to the SUDO_* ... 10 ~/.profile is the right place for environment variable definitions and for non-graphical programs that you want to run when you log in (e.g. ssh-agent, screen -m). It is executed by your login shell if that is a Bourne-style shell (sh, ksh, bash). Zsh runs ~/.zprofile instead, and Csh and tcsh run ~/.login. If you log in under an X display manager (xdm, ... 10 It's because your root user has a different path. sudo echo$PATH prints your path. It's your shell that does the variable expansion, before sudo starts (and passes it as a command line argument, expanded). Try: sudo sh -c 'echo $PATH' 10 You can't do this without a nasty hacks - there's no API for this, no way to notify the process that its environment has changed (since that's not really possible anyway). Even if you do manage to do that, there is no way to be sure that it will have any effect - the process could very well have cached the environment variable you're trying to poke (since ... 9 If you use the env command to display the variables, they should show up roughly in the order in which they were created. You can use this as a guide to if they were set by the system very early in the boot, or by a later .profile or other configuration file. In my experience, the set and export commands will sort their variables by alphabetical order, so ... 9 I think you're confused about terminology. An "environment variable" is merely a shell variable that any child processes will inherit. What you're doing in your example is creating a shell variable. It's not in the environment until you export it: MY_HOME="/home/my_user" export MY_HOME puts a variable named "MY_HOME" in almost all shells (csh, tcsh ... 9 The answer to your question can be found in INVOCATION section of man bash. Here's relevant excerpt: When bash is invoked as an interactive login shell, or as a non-inter- active shell with the --login option, it first reads and executes com- mands from the file /etc/profile, if that file exists. After reading that file, it looks for ... 9 su -c "echo$hi" bela expands to the words su, -c, echo ​ and bela. Since the variable hi is not defined in your current shell, its expansion is empty. The command that is executed as user bela is echo ​. Fix: su -c 'echo $hi' bela, with the single quotes protecting the$ from expansion… Not. The .bashrc file is only read by interactive shells. When you run ...

9

Using su without -l or - starts bash as an interactive, but non-login shell, which doesn't read from either of the files you specified. Use the -l or - option or put the relevant config into /root/.bashrc. Quick summary of config files: Login shell (-l/--login) reads /etc/profile first, and then the first it finds of: ~/.bash_profile, ~/.bash_login, and ...

8

there is none but: setenv is the name of the command in the *csh family of shells export is the name of the command in the "other" family of shells (ash, bourne, bourne again, zsh) and, ok, the syntax is slightly different. but other than that? none.

8

Inkscape, being a GTK application, uses the GLib g_get_home_dir function to find the user's home directory. As documented in that link, g_get_home_dir does not consult $HOME, but rather /etc/passwd. You'd have to patch Inkscape to check$HOME first (as shown in that link).

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