Tag Info

Hot answers tagged

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.


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.


16

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


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


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


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


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

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.


6

tar -czf backup.tgz "$exclude1" "$exclude2" ${exclude3+"$exclude3"} 2>&1 ${exclude3+"$exclude3"} expands to nothing, if $exclude3 is unset, and to "$exclude3", if it is set. (and similarly for the other variables that are potentially unset.) Note that there is a difference between an unset variable and a variable that is set to the empty string, ...


6

Most common variants: display short version of application help with clause "To view full help type app-name --help"; display credits and license; "error: no operation specified (use -h for help)".


6

Alternatively you can take advantage of the Readline library in Bash. This is a bit of a workaround, but relatively easy to type. ls /some/path/ rm ESC.file1 ESC.file2 (Assuming your meta prefix is the ESC key.) The extra ls in the first command puts the path in the history as the last argument of the previous command, ESC. (or as the manual states M-. ...


6

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


6

xsel | while read line; do mycommand "$line"; done Or something similar. You can also use xargs, which is a very powerful command for manipulation of command line arguments.


6

Many of the compressors take an an environment variable to accept options that cannot be passed on the command line. In your case GZIP_OPT=-9 sort --compress-program=/bin/gzip The same is true for xz with XZ_OPT and bzip2 with BZIP2


6

The probably closest syntax to that is: p_out='/some/path' arg_1='5' my_script


6

You're interpreting the man page wrong. Firstly, the part about -- signalling the end of options is irrelevant to what you're trying to do. The -c overrides the rest of the command line from that point on, so that it's no longer going through bash's option handling at all, meaning that the -- would be passed through to the command, not handled by bash as ...



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