Tag Info

Hot answers tagged

14

Normally xargs will put several arguments on one command line. To limit it to one argument at a time, use the -n option: $ seq 3 | xargs -n 1 echo 1 2 3 Documentation From man xargs: -n max-args Use at most max-args arguments per command line. Fewer than max-args arguments will be used if the size (see the -s ...


6

You can try things out with a script such as #!/bin/sh for fd in 0 1 2; do if [ -t $fd ]; then echo $fd is a TTY; fi done Running this I see that: if the script is run on its own, all three FDs are TTYs if the script is run at the start of a pipeline, stdin and stderr are TTYs if the script is run in the middle of a pipeline, stderr is a TTY if the ...


5

A bit more research revealed the answer from Make xargs execute the command once for each line of input: $ seq 1 3 | xargs -L 1 echo 1 2 3


4

Depending on your current file probably this would do: awk ' /^stdout:/ { print substr($0, 9) } /^stderr:/ { print substr($0, 9) > "/dev/stderr" } ' output It could get a bit more elegant with some changes to your "recording script".


3

First, let's look at what we see in the terminal: $ echo <(vim) /dev/fd/63 $ Vim: Warning: Output is not to a terminal Notice that you get a prompt back immediately, without waiting for the editor to terminate. Process substitution doesn't wait for the command to finish, it creates a pipe between the command and the shell. A name for that pipe is ...


3

It's because your input stream is feeding both read. You're almost right, so maybe it's a typo (you just forgot to give to right FD to your second read) : while IFS=',' read a b c; do read input <&3 echo $input done 3<&0 < input.csv >> output.txt


3

while …; do echo "$fname" >&1 done > logfile The standard output of the echo command is redirected to its standard output. In other words, >&1 is a no-op. The 1 in >&1 designates file descriptor 1 of the command where it is used, not of some mysteriously-chosen outer scope. To redirect to a file that is available at an outer ...


2

Your while loop is non-interactive, thus doesn't have a tty. You have to save your tty device before entering the loop. So you'd have something like: my_tty=$(tty) while read fname fpath dname dpath ; do echo "$fname" | tee ${my_tty} echo "$fpath" echo "$dpath" diff "$fpath/$fname" "$dpath/$dname" | tee ${my_tty} done > logfile


2

cat << EOF >&2 ... EOF Or: cat >&2 << EOF ... EOF or: >&2 cat << EOF ... EOF Or: usage() { cat << EOF ... EOF } >&2 function usage { is the ksh syntax. It only makes sense in the AT&T implementations of ksh where functions defined that way behave differently. In other shells, that ...


2

You don't say what shell are you using. From the behaviour you are describing it's likely zsh. If you have a look in its man page you would notice how redirections are handled. Note that a pipe is an implicit redirection; thus cat bar | sort <foo is equivalent to cat bar foo | sort (note the order of the inputs). Otherwise, regular ...


2

Your understanding is not quite correct. In a | b the stdout output of process a connected through a pipe to stdin of process b. The problem with your code is that with an additional redirection from somefile to process b you will use two different methods at the same time to connect to stdin of process b. Don't do that! The question is; what do you try to ...


2

if your test.bash looks like this: echo "Hello World!"; echo error >&2 this script loop.sh: ./test.bash &> original ; echo original: ; cat original; ok=0 ; er=0 for i in {1..100}; do rm output ; printf "(ok%d:er%d) running again: " $ok $er ./test.bash 2> >(cat >>output) > >(cat >>output) #<-EXAMINED ...


1

The redirection to file.txt at the end of your paste command is truncating your file before paste has a chance to read it. Try echo 2 | paste file.txt - > file2.txt or if you have sponge installed echo 2 | paste file.txt - | sponge file.txt


1

Most shells restrict the name of functions to contain only characters that don't need to be quoted, which excludes >. Even in the few shells that allow > as a function name (I only know of zsh), defining a function called > would only have an effect if you called > as a command (which would require quoting it, i.e. running \> or ">" or ...


1

The > has a special meaning in the shell, it's a redirection operator, see the manpage: [n]> file Redirect standard output (or n) to file. The name of a function can contain only letters (a-z or A-Z), digit (0-9) or the underscore character (_). Also is must not begin with a digit. (see Function Definition Command and Name)



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