Tag Info

New answers tagged

0

&> /dev/null throws away both stderr and stdout. Same answer as the others, just a few characters shorter.


1

You can use command grouping: { ps -p "$proc" | fgrep "$proc";} >/dev/null 2>&1 or wrap pipe in subshell: (ps -p "$proc" | fgrep "$proc") >/dev/null 2>&1


-1

redirect error stream to null like ps -p $proc 2> /dev/null | fgrep $proc > /dev/null 2>&1


-1

First off, that isn't how you pipe something to grep. Also, it is generally considered better form to separate commands from the conditional and just check return codes. Something like the following works perfectly: command=`ls -l` for file in "$command" do echo "$file" | grep 'o' if [ $? -eq 0 ]; then echo "$file" fi done


10

$file | grep -o executes the command specified by the value of file and pipes its output to grep. But that's clearly not what you wanted. If you want to list files that contain o You meant the value of file to be an input file for grep, not a command to execute. So you need an input redirection, not a pipe. if grep 'o' <"$file" grep reads from ...


1

You should not rely on ls output at all. ls is meant to show human friendly output and not to be used within scripts. See the following example; for f in ./* do if [[ $f = *o* ]]; then printf '%s\n' "$f" fi done


5

You're trying to execute $file. Instead, you must echo it: # ... if echo "$file" | grep 'o' ; # ... Note that the grep will already print the filename, so you should silence it (e.g. grep -q 'o' or grep 'o' >/dev/null). You're also passing -l to ls, which you don't want to do. ls -l prints the file name and attributes, and you'll be matching against ...


0

When you run ssh, the standard input is passed to the remote command. The remote command doesn't actually do anything with it, but the local ssh process has no way to know. To avoid this, since you don't want to pass any input to the remote command, redirect the input of ssh to /dev/null. Don't forget to double quote variable substitutions. while IFS= ...


0

The default standard input handling of ssh drains the remaining line from the while loop. To avoid this problem, alter where the problematic command reads standard input from. If no standard input need be passed to the command, read standard input from the special /dev/null device.


0

Depending on how early in the boot you want this to run, you may want to use cron @reboot. (You may need to play with environmental variables.) Then wrap it in a detached terminal. tmux new -d '/path/to/python /full/path/program/proxy.py' # or # screen -d -m '/path/to/python /full/path/program/proxy.py' Effectively these are backgrounded to synthetic ...


-1

Here is a simple example. It should give you a enough info to get started. #!/bin/bash #conversor.sh #Author.....: dede.exe #E-mail.....: dede.exe@gmail.com #Description: Convert all files to a another format # It's not a safe way to do it... # Just a desperate script to save my life... # Use it such a last resort... ...


1

If the first argument to the script is jobname and the second is command1 && command2 && command3 then the command you build up in the joined variable is something like command1 && command2 && command3>> /path/to/cron/log/dir/May_12_2015/jobname_2015-05-12_01-09-25.log 2>&1 You call eval on this string, and ...


1

Adding #!/bin/bash did the thing, I just forgot to add that line. Can't really tell, why it does not work on the shell, but somehow it now works inside the script and inside the cronjob. Thanks for the comments.


5

You wrote in your last block, linux$ paste temp2 temp > temp2 You cannot do this. (Well you can, but it won't work.) What happens here is that the shell truncates temp2 ready to send output from the paste command. The paste temp2 temp command then runs - but by this stage temp2 is already zero length. What you can do instead is this, which uses a ...



Top 50 recent answers are included