Tag Info

Hot answers tagged

41

- is defined in POSIX Utility Syntax Guidelines as standard in: Guideline 13: For utilities that use operands to represent files to be opened for either reading or writing, the '-' operand should be used to mean only standard input (or standard output when it is clear from context that an output file is being specified) or a file named -. You can see ...


39

This is not a bug in the cp command. When you enter cp *.pdf, cp never sees the actual wildcards because the wildcards are expanded by bash, not by cp. How will cp know that you have entered only one argument? This is a side effect of bash wildcards and cannot be called a bug.


31

cd - is actually shorthand for cd "$OLDPWD" && pwd, where $OLDPWD is set each time you change directories to the directory you were just in. Handling of - depends on the application. Some applications use - to signify STDIN, e.g. grep, awk Other applications may use - as a shorthand for anything they choose, as Michael's answer specifies, with su, ...


30

You can use the process substitution operator <() of bash (or zsh): 4s-import <(zcat huge.gz) This operator will create a temporary fifo /dev/fd/NN and replace <(.) with the string /dev/fd/NN. 4s-import now can open /dev/fd/NN and read from that fifo, while bash will run zcat huge.gz, which sends its output to /dev/fd/NN.


19

You seem to understand what is happening perfectly well. In your example, *pdf indeed expands to file1.pdf file2.pdf this_is_a_folder.pdf. I don't see what's confusing you. cp is doing exactly what it should, you are telling it to copy file1.pdf and file2.pdf into this_is_a_folder.pdf and that is exactly what it is doing. There is no bug, it is working as ...


18

You're close: rm /some/path/{file1,file2} or even rm /some/path/file{1,2} Related, and supported by other shells, is a pattern like rm /some/path/file[12] The first two are expanded to two explicit file name arguments; the third is a pattern against which all files in /some/path are matched.


18

Though Michael mentions that su and other applications can use - to mean whatever they want (read from stdin is common), Git does use - in a fashion similar to how cd does, for changing branches. $ git status On branch master $ git checkout foobar $ git status On branch foobar $ git checkout - $ git status On branch master


17

When they are not quoted, $* and $@ are the same. You shouldn't use either of these, because they can break unexpectedly as soon as you have arguments containing spaces or wildcards. "$*" expands to a single word "$1c$2c...". Usually c is a space, but it's actually the first character of IFS, so it can be anything you choose. The only good use I've ...


16

Any program can use - as an argument, to mean whatever they want. One common example is su, which uses - as shorthand for --login. The only convention I can think of is that programs that read from files frequently use - to mean "read from stdin", but it's entirely up to the program


15

Many programs have a - as standard input. If yours does, use that as it's "builtin". You can also try using /dev/stdin or /dev/fd/0 as a file. A third option is to use mkfifo to create a fifo special file. In one shell you pipe in your data (eg. gunzip > your_fifo_file), while in the other you call your program with the fifo as the file.


13

Here is a simple script to demonstrates the different between $* and $@: #!/bin/bash function test_param() { echo "Receive $# parameters"; echo Using '$*'; echo for param in $*; do echo "==>$param<=="; done; echo echo Using '"$*"'; for param in "$*"; do echo "==>$param<=="; done; ...


13

The POSIX utility syntax guidelines (specifically #13) specify that for utilities that expect a file name to read from, - means standard input, and for utilities that expect a file name to write to, - means standard output. For example, cat somefile - copies the content of somefile to its standard output, followed by what it reads on its standard input. ...


12

ps does not hide the password. Applications like mysql overwrite arguments list that they got. Please note, that there is a small time frame (possible extendible by high system load), where the arguments are visible to other applications until they are overwritten. Hiding the process to other users could help. In general it is much better to pass passwords ...


12

There are two common ways to provide inputs to programs: provide data to STDIN of the processes specify command line arguments kill uses only command line arguments. It does not read from STDIN. Programs like grep and awk read from STDIN (if no filenames are given as command line arguments) and process the data according to their command line arguments ...


11

Short answer: use "$@" (note the double quotes). The other forms are very rarely useful. "$@" is a rather strange syntax. It is replaced by all the positional parameters, as separate fields. If there are no positional parameters ($# is 0), then "$@" expands to nothing (not an empty string, but a list with 0 elements), if there is one positional parameter ...


11

You can simply use xargs xsel | xargs -n1 echo mycommand -n1 means one arg for mycommand, but it's just dry run, it will show what going to be run, to run it remove echo For constant Argument xsel | xargs -I {} -n1 echo mycommand "constantArgument" {}


9

You're in zsh, not bash. In zsh, repeat (inspired from csh repeat) is a construct used to repeat commands. repeat 10 echo foo Would echo foo 10 times. If you want to call your repeat, you'd need to quote it so that it's not taken as the repeat reserved word. $ echo $ZSH_VERSION 5.0.2 $ 'repeat'() echo "$*" $ type -a repeat repeat is a reserved word ...


9

I believe you can use fgrep -- --help to achieve this. The man page mentions fgrep -e --help Quote from http://www.openbsd.org/cgi-bin/man.cgi?query=grep: -e pattern Specify a pattern used during the search of the input: an input line is selected if it matches any of the specified patterns. This option is most useful when multiple -e ...


8

They're completely different. Command-line arguments are passed to the program in an array and it can do what it wants with them; stdin is an input stream the program has to request data from. Programs that process files often choose to support both, but they have to do so manually -- they check if a filename was passed as a command-line argument, and if not ...


8

Dashes are used to denote options, which modify the behavior of the command. Arguments without dashes denote the main parameters of the command, often these are filenames. Single hyphens usually introduce options consisting of just one letter. Multiple such options can be grouped together, so ls -a -l can be abbreviated as ls -al. This was the standard ...


8

This is an interesting question, and it deals with a part of the Unix/Linux philosophy. So, what is the difference between programs like grep, sed, sort on the one hand and kill, rm, ls on the other hand? I see two aspects. The filter aspect The first kind of programs is also called filters. They take an input, either from a file or from STDIN, modify ...


8

As far as I can tell, the use of -- as end-of-options-marker starts with sh and getopt in System III Unix (1980). According to this history of the Bourne Shell family, the Bourne Shell first appeared in Version 7 Unix (1979). But it didn't have a way for set to separate options from arguments. So the original Bourne shell could do: set -e - turn on ...


7

This can be done using command substitution, like so: mvn -Dvar_name="$(cat /path/to/file)" # POSIX mvn -Dvar_name="$(</path/to/file)" # bash This has a notable caveat, though, namely that all trailing newlines are stripped. If that doesn't matter, though, then that should work. If you really just want to read one line, you could use read instead, ...


7

The code you provided will give the same result. To understand it better, try this: foo () { for i in "$*"; do echo "$i" done } bar () { for i in "$@"; do echo "$i" done } The output should now be different. Here's what I get: $ foo() 1 2 3 4 1 2 3 4 $ bar() 1 2 3 4 1 2 3 4 This worked for me on bash. As far as I know, ...


7

That depends what kinds of arguments your application expects. If it processes files, it's traditional to read from standard input and write to standard output if no arguments are specified (example: cat, tee, …). If the application has an interactive mode, start it if no arguments are specified (example: sh, ed). If the application expects an object to work ...


7

Since you're working in bash, use an array. excludes=() excludes+=('--exclude=/path/*') … tar -czf backup.tgz "${excludes[@]}" If you have an optional entry in some variable, add it in a conditional. if [[ -n $exclude_or_empty ]]; then excludes+=("$exclude_or_empty"); fi


7

I just can give you an overall answer: Command line options are often parsed using the library function "getopt". Originally it only accepted aguments consisting of a - followd by a symbol. This effectively limits the amount of options you have, more or less -A to -Z, -a to -z and -0 to -9. You can imagine that you will not use an option without at least a ...


7

There's a special syntax for this: for i do echo "$i" done More generally, the list of parameters of the current script or function is available through the special variable $@. for i in "$@"; do echo "$i" done Note that you need the double quotes around $@, otherwise the parameters undergo wildcard expansion and field splitting. "$@" is magic: ...


7

It's not a bug, it's a side-effect doing of wildcard expansion once in the shell rather than implementing it in every program. Now, there are some much stranger ways you can trip yourself up with this, especially by creating files whose names start with "-". For example (in an empty directory): $ touch -- --version $ ls --version $ rm * rm (coreutils) ...


7

This should work: pkill name I also suggest reading the man page.



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