Tag Info

Hot answers tagged

3

When you leave a variable expansion unquoted, it undergoes word splitting and filename expansion (i.e. globbing). It isn't parsed as a shell command. In general, when you dynamically construct a shell snippet to execute, the right way to execute it is eval "$a" where a contains the string to parse as shell code. In your first snippet, the value of a is the ...


3

A long, long time ago: This document details the changes between this version, bash-2.05a-rc1, and the previous version, bash-2.05a-beta1. Changes to Bash … w. Bash no longer auto-exports HOME, PATH, SHELL, or TERM, even though it gives them default values if they don't appear in the initial environment. I don't know what ...


2

Assign to a variable var=$(awk 'NR==1{a=$0}NR==2{print $0/a}' test.txt) or output to a file: awk 'NR==1{a=$0}NR==2{print $0/a}' test.txt > output


2

When you run sudo su -l -c "echo $PATH", $PATH is expanded in your original shell, because the double quotes do not prevent this expansion. You want sudo su -l -c 'echo $PATH' to expand in the su shell instead. I assume a follow-up question will be "then how do I get java to run"? I would suggest either calling java with its full path, or, and this may or ...


2

You can get this behavior with set padhour: ubuntu:~> set prompt="%P>" 0:36:02> 0:36:03>set padhour 00:36:07> Also tested on FreeBSD 10. From the man page: Special shell variables padhour If set, enable the printing of padding '0' for hours, in 24 and 12 hour formats. E.G.: 07:45:42 vs. 7:45:42.


2

A simple solution might be to have these variables set in a file, making that file world-writeable and sourcing it from /etc/bash.bashrc. That way, the variables would be available to all users, any change in the sourced file would be kept after reboot and would also be available to any new shells started. Note that any open shells will not have their values ...


2

What I think you're trying to do needs eval in order to work: THING="eval kill \$(pgrep myAppName)" $THING but it's awkward and doesn't work by default in all shells (for example it doesn't work by default in zsh although an option can be set to make it work). Whatever you are trying to do is most likely better solved with something cleaner and easier ...


2

The default PATH is set in /etc/profile. Users can modify their PATH by editing ~/.profile, ~/.bash_profile or ~/.bashrc (if they're running bash) but if they don't they will still have a PATH as defined in /etc/profile. That's why the line was PATH=$PATH:$HOME/bin and not just PATH=$HOME/bin That way, the original value of PATH is kept and the new ...


1

Suppose the following bash : #!/bin/bash echo $# And you run such as : ./arg.sh g jt t uu It return 4, 4 is number of argument that you pass to your shell. It's very good to investigate your parameters of your shell script. Supppose i have the following usage of program : --value PATTERN -o PS_COMMAND_OPTIONS Then I can investigate such as the ...


1

Traditional sh reads the file ~/.profile at startup when it's a login shell. Bash, which is backwards compatible with sh but offers additional features, reads .bash_profile, and if that doesn't exist, tries .profile instead¹. This allows you to have a .profile for plain sh and a .bash_profile taking advantage of bash's extra features when your login shell ...


1

dhag explained why $PATH appears to be correct, even though it isn't. The reason the path doesn't get changed is most likely that su doesn't run the shell interactively, meaning that either bash.bashrc doesn't get executed in the first place, or that it quits before doing anything because it detects that it's not running interactively. You'll either have ...


1

quotient=$(dc -f test.txt -e 'r[num desired precision]k/p')


1

As the sudoers settings vary between OSes it is hard to predict what would work for you. sudo -EH the H switch tries to set $HOME to the target user's value, but this would not preserve $ZDOTDIR. Or add the line below to the end of sudoers using visudo. This tells sudo to keep the variables listed from the current environment. In this case you would then ...


1

No, X doesn't mangle environment variables. But bash does; specifically, it unsets PS1 and PS2 in non-interactive shells: $ PS1='my PS1' PS2='my PS2' PS3='my PS3' PS4='my PS4' bash -c export |grep PS declare -x PS3="my PS3" declare -x PS4="my PS4" Bash is probably executed somewhere as part of your login sequence. That's guaranteed if your /bin/sh is bash ...



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