New answers tagged

1

The problem is that you cannot guarantee which is executed first. So you have to delay unlinking and writing to the file until you are absolutely sure that the file is opened for reading. This will buffer the file in RAM before writing it. cat foo | perl -e 'undef $/; @out=<>; open WRT,">",shift; print WRT @out' foo Advantage: Keeps ...


1

You can't simply do that because the tee command overwrites the file, making it shorter (probably) and eliminating the cat command's ability to read the data that was in the file. If you could ensure that programs such as tee opened a new file, and if the shell guaranteed that cat opened its copy first, then you could copy from the old (actually deleted) ...


4

That's right. > truncates the file before the command is started, so the command sees an empty input file. It doesn't actually matter that the redirections are performed from left to right (except that you'll get an error if the file doesn't exist, whereas >file <file would create the file first). With somecommand <file >>file, most of the ...


1

Using the same file for both input and output is guaranteed to give you problems. The problem will start as soon as the shell opens both files because the output file will get truncated. If you append to the output, then it will loop indefinitely until the disk is full or the max file size is reached.


2

It's worth observing that the shell must establish redirections before starting the program. Consider your example: ./write_file.py >> ~root/log What happens in the shell is: We (the shell) fork(); the child process inherits the open file descriptors from its parent (the shell). In the child process, we fopen() (the expansion of) "~root/log", and ...


0

I think you can just do this (in Bash) using the --keep option. gunzip -vfk file.txt.gz &> file.txt.log The --keep option is -k --keep Keep (don't delete) input files during compression or decompression.


0

I'm sorry to inform you that it is quite the opposite. The shell needs to open it's I/O first and then passes control to the program. tee might prove helpful in this case: ./write_file.py | tee -a ~root/log > /dev/null


10

From the bash man page, section REDIRECTION (emphasis by me): Before a command is executed, its input and output may be redirected using a special notation interpreted by the shell. ... A failure to open or create a file causes the redirection to fail. So the shell tries to open the target file for stdout, which fails, and the command isn't ...


16

It's not really a question of ordering checks, simply the order in which the shell sets things up. Redirections are set up before the command is run; so in your example, the shell tries to open ~root/log for appending before trying to do anything involving ./write_file.py. Since the log file can't be opened, the redirection fails and the shell stops ...


10

The messages you mention are not printed to standard output but to standard error. So, to capture them, you either need to redirect standard error instead of standard output: sudo -u user bash -c "git clone https://github.com/foo.git ~/foo 2>> log" Or both STDERR and STDOUT: sudo -u user bash -c "git clone https://github.com/foo.git ~/foo >> ...


1

git clone https://github.com/scrooloose/nerdtree.git /home/test_user/.vim/bundle/nerdtree &>> /var/log/build_scripts.log


2

The time builtin of bash shows timing info on STDERR after the command after it (the actual one) returns. So unless you grouped them and pass the STDERR of the group to a file, only the actual command's STDERR will be redirected to the file and the file will be closed when command returns (prior to time shows its info). You can use command grouping, ...


2

Let's start with saving the file somewhere first. Take your command: find -type f -exec grep -il "xml" {} \; and read through: What are the shell's control and redirection operators? to where it says: > : Directs the output of a command into a file. to make your command something like: find -type f -exec grep -il "xml" {} \; > ...


0

To terminate a w command in sed, you need an end of line or an end of string. You can either embed a literal newline in your sed command (which is rather irritating for interactive use) or you can use multiple -e commands. So instead of: sed -n "/PUBLISH/{s|.*\('.*',\).*|\1$(date),|;N;s/\n//;w qwerty.txt}" You would use: sed -n -e ...


0

In BSD check the watch command. Otherwise please check the following example using strace (where 7214 is your PID): strace -e trace=write -s1000 -fp 7214 2>&1 \ | grep --line-buffered -o '".\+[^"]"' \ | grep --line-buffered -o '[^"]\+[^"]' \ | while read -r line; do printf "%b" $line; done For further explanation or more examples, check: How to ...


0

In BSD, you can use watch which snoops a given tty, e.g. watch /dev/pts/0 In Linux, it won't be possible if the process wasn't run under multiplexer before such as screen or tmux. See also: Reptyr: Attach a Running Process to a New Terminal It seems the only way is to debug the process (e.g. strace, dtrace/dtruss, gdb, lldb, etc.). Since you've used ...


1

For redirection, I would assume this (redirection) is implemented by the shell replacing stdin (by input for < input) and stdout (by output for > output) using dup2() - open files for input and output in = open() out = open() dup2(in, 0) // replace input file with stdin dup2(out, 1) // replace output file with stdout close(in) ...


0

You can use Vim in Ex mode: ex -sc '%!shuf' -cx example.txt % select all lines ! run command x save and close


0

You can use Vim in Ex mode: ex -sc '%!iconv -f cp1251 -t utf8' -cx "$file" % select all lines ! run command x save and close


0

You can use Vim in Ex mode: ex -sc '%!git stripspace' -cx project/code.m % select all lines ! run command x save and close


0

You can use Vim in Ex mode: ex -sc '%s/^ *//|x' file1.txt % select all lines s substitute x save and close


1

You can use Vim in Ex mode: ex -sc '2,d|x' .hgignore 2, select lines 2 until end d delete x save and close


1

"redirection" is a concept of the shell, and the details around it depend on which shell you are talking about. Though, one might say that the basis for redirection rests with the notion that programs have pre-opened input and output file descriptors when they start, which traces back to how the execve function works. Namely that the child process inherits ...


3

It depends on what mycommand does. If it sleeps for 10 minutes then starts to read its standard input, it will see your modifications if they have already been done. If it does a first read of part of the file, then you modify the file, and it does a second read, it will see changes that are beyond the point that is has read. Also, because of the buffering ...


-1

cat "$usernameFile" | while read line; do if [[ "$line" != " " ]]; then zgrep -w "$line" "$logFile"* >> grep_output.txt fi done


6

There are two place where you input "$usernameFile": one in the global loop, the other in read. while read -r line < $usernameFile; do done < "$usernameFile" you should input it only in global loop I think. (In other words, only put it after "done".)


2

Move the >> /ROUTE/output_file.txt from where it is now to the telnet line, so that line becomes } | telnet 172.22.89.133 >> /ROUTE/output_file.txt


1

Try the sed -u (-lon BSD/Mac OSX systems), and grep --line-bufferedoptions.


1

You seem to expect the out2 and out3 being written in real time, but sed and grep in pipe wait for the EOF. And nothing fails here. Kill openssl from another console and check if you have correct results in out2 and out3.



Top 50 recent answers are included