Tag Info

New answers tagged

0

Use echo with the -n switch: echo -n "blah blah" >> file


0

You can run: ssh remote_server "command" > file_on_local_host.txt or use the output as an input for local command: ssh remote_server "remote_command" | local_command


2

General, you can always do: <command> | ssh user@remote-server "cat > output.txt" It saves output of <command> to output.txt file in remote server. In your case, on Server-1: echo "qwerty" | ssh user@Server-2 "cat > output.txt" If two servers have no connectivity, but you can ssh to both servers, then from local machine, you can do: ...


0

In any shell that's compatible with Bourne or POSIX,  redirections are processed from left to right, and the pipe comes first. Thus your command is executed in this way (I omit what happens in subprocess 2): Create a pipe. Fork two subprocesses, 1 and 2. Redirect the standard output of 1 to the pipe. Redirect the standard output of 1 to file. In 1, execute ...


4

Yes, this is job for tee: rpm -qa | tee file | wc -l In this construction a | b a's stdout goes to stdin of b. In case of a > file | b all output form a goes to file and nothing goes to b stdin. tee command make a copy of all it receives on stdin to both file and stdout.


3

Yes, this is a job for tee: rpm -qa | tee file | wc -l Shell redirection (>) is just that — redirection — and you can only point the output stream to one other place at a time. There's nothing left for the | to see at that point. tee is made for just this purpose, where you want to split the stream into two parts, one going into a file and one still on ...


1

rpm -qa > file ; wc -l file should do what you want.


1

netcat springs to mind; it may be the more sensible choice (given the no-overhead, no compression approach to network communications) on your low-spec receiving machine. A nice usage example can be found here: http://stackoverflow.com/questions/4113986/example-of-using-named-pipes-in-linux-bash


0

The redirection < out causes the named pipe to be opened for reading. This blocks as long as no process has the pipe open for writing. Meanwhile, the right-hand side of the pipeline is blocking in the read command, waiting for nc (which hasn't started yet) to output something through the pipe. It's a deadlock. To allow the script to proceed, make sure ...


0

Change /etc/default/cron # Or, to log standard messages, plus jobs with exit status != 0: # EXTRA_OPTS='-L 5' # # For quick reference, the currently available log levels are: # 0 no logging (errors are logged regardless) # 1 log start of jobs # 2 log end of jobs # 4 log jobs with exit status != 0 # 8 log the process identifier of child ...


0

TL;DR Open your log file in append mode: cmd >> log Then, you can safely truncate it with: : > log Details With a Bourne-like shell, there are 3 main ways a file can be open for writing. In write-only (>), read+write (<>) or append (and write-only, >>) mode . In the first two, the kernel remembers the current position you (by ...


2

This is probably the single most confusing, and annoying thing when working with ssh (at least in my opinion). The reason for this behavior is that ssh does not preserve arguments when executing a remote command. It takes all your arguments, and concatenates them together separated by spaces. So when you run ssh remote sh -c 'echo hi > hi.txt' In ...


3

I think your local shell is stripping off your quotes. You could try ssh remote sh -c '"echo hi > hi.txt"' When you send remote commands with ssh there are two shells involved with the reading of each line sent. Your local shell and your remote shell. A good explanation of this can be found at Unix/Linux Shell Quoting for remote shells


5

Just write a subshell which sends to stdout and stderr... (echo STDOUT && echo STDERR >&2) For proof that it works: (echo STDOUT && echo STDERR >&2) > STDOUT.txt 2> STDERR.txt This will create files STDOUT.txt and STDERR.txt containing the words STDOUT and STDERR respectively.


2

ls / /x df / /x wc / /etc/passwd od / /dev/null To guaranteed stdout written before stderr: (w;/) # Bourne/csh like shells only. sh -c 'w;/' 'time' w


1

You can write a function to use later: gen_stdout_stderr() { printf "%s\n" "STDERR" >&2 printf "%s\n" "STDOUT" } Then: $ gen_stdout_stderr STDERR STDOUT


4

A simple approach would be to use ls to list actual and imaginary files: ls . *.blah This assumes that there are visible files in the working directory and that you don't have any files that end in .blah1 1. ...and if you do, we won't judge you.


0

What you have is a null command with redirection.  You haven’t specified which shell you’re using.  vinc17 has addressed the handling of null commands in zsh.  In bash, a null command is simply a do-nothing; like an empty script.  You can infer this if you read between the lines in the Bash Reference Manual: When a simple command is executed, the shell ...


2

The race condition is already identified. But if you'd like an easier solution, you don't need a separate wc to count the records, awk can do it: awk '{if($2!~/\*/){print $1;++n}END{print n >"n.txt"}' tmp | sort | uniq -c ... Beyond that, awk can count like sort|uniq -c as long as the values fit in memory, and also do the x/n calculation, but may ...


5

pipe expression in process substitution causes a race condition in bash and ksh, zsh doesn't. The main problem here is that zsh waits, bash doesn't. You can see more details here. A quick fixed, adding sleep 1 in your awk to make n.txt always available: awk 'BEGIN{system("sleep 1");getline n < "n.txt"}{print $1 "\t" $1/n*100 "\t" $2}'


13

Your redirections have a race condition. This: >(wc -l | awk '{print $1}' > n.txt) runs in parallel with: awk 'BEGIN{getline n < "n.txt"}...' later in the pipeline. Sometimes, n.txt is still empty when the awk program starts running. This is (obliquely) documented in the Bash Reference Manual. In a pipeline: The output of each command in ...


2

It depends on the shell. With zsh, this is described under Section "REDIRECTIONS WITH NO COMMAND". By default, READNULLCMD will be used as the command, which defaults to more.


3

So I just executed "< ./somefile.txt" in linux shell, Under bash, dash, and similar shells, that do not execute a command. That merely assigns somefile.txt to stdin. This goes nowhere because stdin is not used unless you supply a command. To use stdin for something try, for example, cat: cat <./somefile.txt Since cat echoes stdin to stdout, ...


1

I looked for sometime into top and there is no straight forward way to do this. As I mentioned earlier, you can use mpstat -P all > top.txt and then run your top command appending >> to output file for per user (you can use grep to filter... but that's a different topic :-). Can you elaborate what exactly the output you want to see (and is it part ...


3

This happens because you're only running the echo command as root. The output redirect is handled by your (non-root) shell. To avoid this, don't use the shell's redirect and use an actual command to handle the writing: tee. What you want to do can be done as so: echo "xyz" | sudo tee test > /dev/null (if you don't redirect the output, tee will output xyz ...


4

process_data() { awk -F /dev/fd/3 3<< \EOF awk code here EOF } Note that command line arguments can contain newline character, and while there's a length limit, it's general over a few hundred kilobyte. awk ' BEGIN {...} /.../ ... END {...} ' If the issue is about embedding single quote characters in the awk script, another approach is ...


3

Why do you need to get the program from stdin? You could use single quotes ('), as Bash let's you split the contents between multiple lines. # awk 'BEGIN { sum = 0 } { sum += $1 } END { printf("sum = %d\n", sum) }' << EOF 1 2 3 EOF


5

You can do: cat /dev/fd/3 3<< E1 /dev/fd/4 4<< E2 foo E1 bar E2 There can be only one stdin, as there's only one file descriptor 0. cat << EOF eof EOF is short for: cat /dev/fd/0 0<< EOF eof EOF And: cat <<< foo is: cat /dev/fd/0 0<<< foo You have to make up your mind what to open on file descriptor 0. ...


1

echo -e "Hello \nWorld \n" >> greetings.txt


6

With socat (version 2 or above): socat 'system:cat input.txt & cat > output.txt,commtype=socketpair' \ 'system:foo,nofork' Or even better: socat 'CREATE:output.txt%OPEN:input.txt' 'system:foo,commtype=socketpair' We're using a socketpair which is bidirectional (pipes are not bidirectional on Linux). Another option is to use a ...


2

cat /dev/null is a no op as it outputs exactly nothing. A simpler way to blank a file's content is then to redirect the null command to it that way: : > file or even, with most shells, only use a redirection without specifying any command: > file The fact the reported size by ls is still high is just due by the writing process seeking to the ...


3

Assuming you meant to say cat /dev/null > file_log.txt the answer is that the process that has the file open for writing did so without O_APPEND, or it sets the offset into the file arbitrarily, in which case a sparse file is created. This is a file that contains "holes", i.e. the system "knows" that there are large regions with zeroes, which are not ...


2

cat /dev/null file_log.txt This only made cat read /dev/null and immediately read file_log.txt and output the result to stdout, your screen. This won't delete anything, at all. If you want to test out, use cat /dev/null non_existent_file and you will see that it errors out. The correct way to truncate a file, is using shell redirectors or any kind of ...


4

Isn't cat reading from the stdin and stores that that into file "filename"? Yes, when cat does not have any filename arguments (or if one of the files is the minus character -), it reads from stdin. Perhaps use of the word "never" by the book is a bit misleading, because: Is the above excerpt from the book just saying that only the particular form ...


2

What is it you are missing? You seem to have understood everything. The > file sends the output to file and 2>&1 sends standard error to standard output. The final result is that both stderr and stdout are sent to file. To illustrate, consider this simple Perl script: #!/usr/bin/env perl print STDERR "Standard Error\n"; print STDOUT "Standard ...


5

You just have to read it left to right: > file --> redirect all thing from stdout to file.(You can imagine you have a link, point-to-point from stdout to file) 2>&1 --> redirect all thing from stderr to stdout, which is now pointed to file. So conclusion: stderr --> stdout --> file You can see a good reference here.



Top 50 recent answers are included