Hot answers tagged

21

In ksh, bash and zsh, time is not a command (builtin or not), it's a reserved word in the language like for or while. It's used to time a pipeline1. In: time for i in 1 2; do cmd1 "$i"; done | cmd2 > redir You have special syntax that tells the shell to run that pipe line: for i in 1 2; do cmd1 "$i"; done | cmd2 > redir And report timing ...


7

It works for me with simplified bash script (only stderr): $ cat seg.sh #!/bin/bash echo "Segfault" 1>&2 $ test=`./seg.sh`; echo "x$test" Segfault x $ test=`./seg.sh 2>&1`; echo "x$test" xSegfault $ test=`eval ./seg.sh 2>&1`; echo "x$test" xSegfault The problem in your case is caused by the fact that Segmentation fault (core dumped) ...


6

There's no command named time wc, time and wc are separated word in shell. Now, there're often two separate program named time, the one is shell keyword, another one is external command. In shells which time is a shell keyword, when you type time wc ..., the shell used its keyword time instead of the external time utility. When the shell uses time keyword, ...


5

I don't even csh, but the manpage says that it's the same thing like &>> in bash and family—that is open for appending (the >>) and also redirect stderr instead of just stdout. The forms involving '&' route the diagnostic output into the specified file as well as the standard output. name is expanded in the same way as '<' input ...


5

You want to use the xargs command: $ ls -ctr | tail -1 | xargs cat This will take the STDOUT of the tail -1 command, and instead of using it as STDIN for the cat command will use it as options to the cat command.


4

The idiom >(...) just means (in layman terms): "the name of a file". And it works as a "name of a file" (sort of, all will be clear in an instant): $ echo <(date) /proc/self/fd/11 Or some other number/name on your OS. But echo does print a name, exactly as if you do: $ echo ProcSubs11 ProcSubs11 And if a file with the label ProcSubs11 exists, ...


4

it seems operationally no different from a simple unnamed pipe. The point is that not every software may support reading from stdin or writing to stdout. Furthermore if you want input from several processes then you cannot tell them apart (without looking at the data itself) with just a pipe: { echo foo; echo bar; } | cat # vs. cat <(echo foo) ...


4

You have put a space between & >, which needs to be &>. This would redirect both STDOUT and STDERR to the file followed next. So you need: nohup sh cp.sh < /dev/null &> /dev/null & If you shell does not support &>, use POSIX way to redirect both STDOUT and STDERR: nohup sh cp.sh </dev/null >/dev/null 2>&1 ...


3

My crystal ball thinks that maybe your message text contains one of more of < or >. It looks to me like your usage mailCommand=`mail -s info@redearmedia.ca < $email` will not do what you want: this will take the content of $email as a filename (failing somewhat because $email consists of several words), try to read its contents, pu tthose into ...


3

you can have the ls filter for only .jpg files ls *.jpg > all.txt


2

Your program just writes on descriptor other then 1 or 2. Consider the following script: #!/bin/bash echo test >$(tty) Now lets run it redirecting both stdin and stderr to /dev/null: $ ./script >/dev/null 2>&1 test As you see we internally redirected output to the terminal, so outside redirection to /dev/null got nothing to do. In your ...


2

The moreutils package contains a program chronic for this purpose. You just call it like chronic my_program args ... Very handy in cron jobs.


2

Because time you're executing is bash builtin. Bash processes it in such special way. If you will use real time binary, it will act exactly in the way you expect it: /usr/bin/time wc file > wc.out 2>&1 Though the output of this time is a bit different: $ /usr/bin/time wc file > wc.out 0.00user 0.00system 0:00.00elapsed ?%CPU ...


2

The message “Segmentation fault (core dumped)” is emitted by bash, not by the program that crashed (when the message is emitted, the program is already dead!). The redirection applies only to the program itself. To redirect messages from the shell itself about the program, run the program inside a shell grouping construct, and redirect the output of the ...


2

In ksh, you can only use single digit for explicit file descriptor. With ksh93r and above, you can open more than 10 file descriptor by using the form: {var}>filename (bash and zsh copied this feature later). ksh will pick available file descriptor greater than or equal to 10, store file descriptor number in variable var: $ exec {var1}>/tmp/test1 ...


2

If you are performing activity on every file in a folder and putting the output file in the same folder, is not a wise approach in my opinion. My > output redirections always end up in /tmp, unless I know there is not enough space for my output there. Then I look for a more suitable filesystem for it. But never place them in the same directory as I am ...


2

Your reasoning is correct. Among your proposed solutions, i prefer the first two specially the second one as it seems cleaner to write to a file located in another directory. Here is another option using GLOBIGNORE variable (Given your shell supports this): GLOBIGNORE=LIST ## "LIST" file will be ignored while globbing for i in *; do echo "$i"; cut -d ' ...


2

The best solution if you plan it in advance is probably to save the descriptors first, or to do your redirections in a subsidiary scope, as in the question linked in the comments. If you didn't do that, though, then you can restore writing directly to the terminal with: exec > $(tty) provided that you haven't redirected standard input as well. If you ...


2

thanks for the response, but I wanted to list everything, not just the .jpg. I realized there is a simple solution to that which is ls * > all.txt instead of ls > all.txt Does anyone know why adding the wildcard would prevent the output file to include itself?


2

A more general solution than the one proposed by @ShayneManning: ls | grep -v '^all.txt$' > all.txt grep is used to filter lines by content. The option -v inverses the filter. So, all.txt will be excluded from the output of ls. All the other names will be printed to all.txt.


2

curl prints its status to stderr rather than stdout. To capture stderr in the same file, you need to redirect stderr to stdout by adding 2>&1 AFTER your stdout redirection: curl -T /home/pi/fb/$DATE.jpg ftp://myftpserver --user myuser:mypass >> /home/pi/fb/log.txt 2>&1 For a thought-provoking question that will help you understand ...


2

messageTemplate=`cat /home/sites/mailmsg.txt` ... mailCommand=`echo "$messageTemplate One or more sites is down"\! | mail -s info@redearmedia.ca` or email="$messageTemplate One or more sites is down"\! mailCommand=`echo "$email" | mail -s info@redearmedia.ca`


1

time writes to stderr. The reason it appears not to is that you are writing the stderr of the current command to /dev/null, not the output of time. This is because time is a keyword that's parsed differently from regular utilities: the redirection is part of the timed command. Using a code block redirects all output. { time ls; } 2> /dev/null Note ...


1

The magic is in the _init_completion function which is defined in the bash_completion file of the bash-completion package. There's no easy way out. If you want sensible fancy completion in bash, install the bash-completion package. Then define a function: . /etc/bash_completion _my_mysql () { local cur prev words cword _init_completion || return ...


1

The message is from a shell that complains about the syntax: & > /dev/null & is indeed a command line that contains a command between two & but this command does not have a command name but just a redirection for stdout. BTW: For those who don't know yet: Since 12 years, Solaris allows to nohup an already running process by calling: nohup ...


1

It is not time that writes the time information. The builtin time makes the shell write this after the command has completed. But redirection affects only the command. In the (time ...) case the redirection is applied to the whole subshell.


1

You need to do: (command > stdout) >& stderr E.g.: (make foo > /dev/tty) >& error.txt The first > redirects the stdout to the tty, then the >& redirects whatever's left into error.txt. In your case, it'd go like this: ~> (make foo > /dev/tty) >& error.txt ~> cat error.txt make: *** No rule to make ...


1

The issue with the example code in the question is subtle; in order to write to a named pipe you need to & background the command, otherwise it will block waiting to be read. However when you do so, "commands started in background with & have their standard input redirected [to] /dev/null.", meaning /dev/null is what's piped into p, rather than ...



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