New answers tagged

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


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`


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


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


0

wc … > ~/log.info | cut ~/log.info | … The two sides of the pipe are executed in parallel. Unless wc is especially quick to finish and cut is especially slow to start, by the time cut reads ~/log.info, it's likely to be still empty, or even nonexistent. To compound the problem, the redirection on sort is also executed in parallel and also truncates ...


0

How about: perl -e 'print sort map {s/(\d).*(\w)\..*//r} <>' (Needs perl 5.14+ - this is probably installed on your system already) Uses an inlined bit of perl code that: reads <> which is STDIN or files specified on command line. Uses a substitution regex which captures a digit (\d) and a letter just before a . (\w)\. then returns the ...


0

You can strip out all of the bits you don't want by piping the output through sed: wc -l ~location/folder/folder/*.log > ~/log.info cut -d "/" -f9 ~/log.info | sort | sed 's_/.*/__;s_\.log$__'


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


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


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


0

You are probably seeing output for standard error (stderr) which is a separate stream from standard out (stdout). It can be redirected with 2>&1 after the output destination. For Example: $ curl -T /home/pi/fb/$DATE.jpg ftp://myftpserver --user myuser:mypass >> /home/pi/fb/log.txt 2>&1


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


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.


3

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


0

You can force the ZSH to clobber on redirect with: >! Same as >, except that the file is truncated to zero length if it exists, even if CLOBBER is unset. or >>! Same as >>, except that the file is created if it does not exist, even if CLOBBER is unset.


0

You could try something like less $(ls -ctr | tail - 1) (the $(...) isn't universal, you might need to substitute backticks). Change less to taste.


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


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.


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


0

Because time is a shell builtin, it writes to the shell's stderr, rather than the command's stderr. Using parentheses forces the whole command into a child shell whose stderr can be redirected. using curly brackets produces a similar result without actually starting a subshell { time who ; } > /tmp/timwho >& /tmp/xx (yes, you need the ...


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.


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


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


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.


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


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


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


0

Use file redirection to save standard out to a temporary file such as /tmp/o $ script.sh > /tmp/o Open browser such as Firefox/Iceweasel, to address: /tmp/o Now select all, copy and paste to Pastebin.org


1

You can use the tools xsel or xclip to translate from X clipboard to stdin/stdout on a terminal. If these aren't installed, they're usually available through your distro's package manager. See the man page for the relevant tool to get details on invocation.


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


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



Top 50 recent answers are included