Tag Info

Hot answers tagged

20

They serve the same purpose (pass the given env vars to the command). However a few notable differences: A=B command is a shell (Bourne/POSIX/rc) construct. For instance, you can do: A=B find . -exec cmd '{}' + or: find . -exec env A=B cmd '{}' + But you can't do: find . -exec A=B cmd '{}' + Because find is not invoking a shell to run that ...


4

set | grep COLUMNS should display “Binary file (standard input) matches” (with GNU grep). muru has correctly identified the culprit: under zsh, IFS contains the null byte in addition to the standard characters space, tab, newline. Run set | grep --text COLUMNS to make grep ignore its inclination to skip binary files. Running set is not a portable, reliable ...


3

Bash variable size is not fixed.It is very likely hold arbitrary amounts of data as long as malloc can find sufficient memory and contiguous address space.Let's assume you stored large large amount of data in your variable.When you try to write data to your file,possibly you will get error something like that /bin/echo ${LARGE_DATA} >> ${YourFile} ...


3

If I were to guess, I'd suspect IFS. set lists IFS too. And for me, IFS is (space, horizontal tab, newline and nul): $ printf "%s" "$IFS" | od -a 0000000 sp ht nl nul 0000004 The presence of the NUL character (\0) causes grep to treat it as a binary file, so depending on your grep, you may see: $ set | grep COLUMNS Binary file (standard input) ...


2

According to the POSIX standard, environment variables are just plain strings with no associated data types. However, as an extension, some shells like bash, ksh, ksh93, zsh and others allow their variables be typed, like being numeric, an array. Read-only variables or pre-formatted ones might also be supported. They are commonly typed with either the ...


2

It looks like a hybrid between Unix shell script and DOS batch script :) In DOS the environment variables are access by enclosing the environment variable between %. Like %PATH%, but in Linux this cannot be done. Just try $ echo %PATH% %PATH% this will not expand the environment variable. But is the script really working ?, because in the later part of ...


2

String interpolation causes this. There are a number of ways to selectively prevent this from happening. The bash hackers wiki has some good examples, though the specifics may vary if you're not actually using bash. In short, you can prevent interpolation with single quotes, or you can escape the characters. [me:~/work]$ export foo=bar [me:~/work]$ echo ...


1

If you do exec bash you will use a fresh & new environnement


1

No Sudo Option You can use the source command to run another bash script in the same environment you came from. (Without launching a subprocess) Script1.sh #!/bin/bash read -p "Enter Your Full Name: " Name source script2.sh Script2.sh #!/bin/bash echo $Name -- With Sudo The reason your example doesn't work is because of the sudo. You can use Sudo ...


1

To expand parameter, arithmetic and command substitutions (and not aliases and other forms of expansions), you could do: my-expand() BUFFER=${(e)BUFFER} CURSOR=$#BUFFER zle -N my-expand bindkey '\e^E' my-expand (it would have similar limitations and could be almost as dangerous as bash's one though).


1

You can set up compinit to expand parameters in your ~/.zshrc: zstyle ':completion:*' completer _expand _complete autoload -Uz compinit compinit This is a minimal setting, if you have compinit already enabled, it should be sufficient to add _expand to the settings of completer There is also the expand-word widget that is by default bound to ^X* (Ctrl+x ...


1

Add the following to your .bashrc: vim ~/.bashrc ... export LD_LIBRARY_PATH=/usr/local/lib This will let you restart your computer, and still have that path assigned.


1

In shell scripting, there is only one data type. Everything is text. Different commands may variously interpret the text to suit their needs: $ [ "1" -eq "01" ] && echo yes || echo no yes $ [ "1" = "01" ] && echo yes || echo no no The first test interprets 1 and 01 as numbers (the second probably as an octal number). The second test treats ...


1

To complete/improve the accepted answer from Tushar, you can: avoid having to escape the slashes in the PATH by using non-slash delimiters omit the -e option, as per the sed man page: "If no -e, --expression, -f, or --file option is given, then the first non-option argument is taken as the sed script to interpret." use the g (global) flag to remove ...



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