Tag Info

New answers tagged

1

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


0

I am doing introductory Linux as also. I see where it means total number of arguments. You can use it like this: #!/bin/bash if [ $# = 2 ] then echo "Your name is $1 $2" else echo "You need two arguments" fi


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


0

The names listed in the LD_PRELOAD variable are looked up in $LD_LIBRARY_PATH, like library names mentioned in the executable itself. So if you want to preload /full/path/to/file.so, you can use export LD_LIBRARY_PATH=/full/path/to export LD_PRELOAD=file.so


0

One ugly solution that will also work: function exec() { args=( $@ ) command=${args[0]} dummy=${args[1]} whoami=`whoami` if [ -z "$dummy" ]; then me=`basename $0` runuser -l ${whoami} -c "bash /etc/init.d/${me} ${command} dummy" else printenv fi } case $1 in status) status ;; ...


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


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


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


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


0

I discovered a typo in my ~/.bashrc. Problem solved.


-1

awk ' NR == 1 { a = $1 } NR == 2 { b = $1 } END { print a print b print b/a } ' data where data is a text file containing, 0250368000 0182885654


-1

I have used an old step by step trick to obtain something that works, but would have liked to do it all in one step. num1=$(awk 'NR==2' test1.txt) echo $num1 #result is 0247421924 num2=$(awk 'NR==1' test1.txt) echo $num2 #result is 0250368000 score=`awk 'BEGIN{printf("%0.0f", '$num1' * 100 / '$num2' )}'` echo $score # result is 99 As you can see, I had ...


1

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


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


0

.bash_profile does not get executed for non-login shells, so if you are running a command and expect it to load in env settings from .bash_profile, that will not happen. Try creating a .bashrc file instead.


0

In so many words; no, a shell you run as a child of your X11 session has no way to change the environment of the X11 session, which is going to be the parent (or possibly grandparent) of processes you start by double-clicking on the desktop. A common workaround is to write the double-clickable tool in such a manner as to connect to some sort of ...


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.


-1

You need to put this in the begining (or anywhere else you want) of your PS1 variable in your .tcshrc file: \D{%H:%M:%S} For example: PS1='(\D{%H:%M:%S}) <\u@\h\W>' The time will be the time when you get the prompt back, it wont update as time goes by.


0

I had the same problem, but for me the solution was different. My user was not configured to use bash as shell, it used zsh as shell instead, therefore the bash dot files were not run at login. Open /etc/passwd with a text editor and look for your username and what shell it uses: root:x:0:0:root:/root:/bin/zsh This is how my user entry looks. Notice it ...


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


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


-1

I'm going to assume you're running bash as your shell. If you're running something else the specifics will vary but the approach will remain much the same. To confirm your login shell, run this command: getent passwd "${USER:-$(id -nu)}" | awk -F: '{print $NF}' I suspect that your prompt is defined in .profile or .bash_profile and is set (once) when you log ...



Top 50 recent answers are included