Tag Info

New answers tagged

3

Here's a summary of some of the drawbacks of: cat $file | cmd over < $file cmd First, a note: there are (intentionally for the purpose of the discussion) missing double quotes around $file above. In the case of cat, that's always a problem except for zsh; in the case of the redirection, that's only a problem for bash or for some other shells only ...


-2

The statement contains two uses of cat. cat file | wc | cat > file2 Clearly the 2nd cat is of no value, as cat file | wc > file2 has the same meaning in all shells I have ever used. However < file wc > file2 does not work in all shells. Not everyone is using a modem shell on a modem version of unix. (It can be off benefit to ...


22

cat file | wc | cat > file2 would usually be two useless uses of cat as that's functionally equivalent to: < file wc > file2 However, there may be a case for: cat file | wc -c over < file wc -c That is to disable the optimisation that many wc implementations do for regular files. For regular files, the number of bytes in the file ...


0

A modern cat implementation (sunos-4.0 1988) uses mmap() to map the whole file and then calls 1x write() for this space. Such an implementation will not loop as long as the virtual memory allows to map the whole file. For other implementations it depends on whether the file is larger than the I/O buffer.


7

Let's suppose prog forks a new subprocess and exits, and the new subprocess writes something to its standard output and then exits. Then the command prog won't wait for the subprocess to exit, and it will display the shell prompt early. But the command prog | cat will wait for an EOF on the stdin of cat, which effectively waits for the subprocess to ...


0

As written in Bash pitfalls, you cannot read from a file and write to it in the same pipeline. Depending on what your pipeline does, the file may be clobbered (to 0 bytes, or possibly to a number of bytes equal to the size of your operating system's pipeline buffer), or it may grow until it fills the available disk space, or reaches your operating ...


14

While I don't disagree with the argument for saying it is a 'useless use of cat', there can be reasons for it: In many languages (including English) words and sentences are read from left to right, so showing the flow of data in the same way can appear more natural to the reader. A reason for the second cat could be to mask the return code. Such as: $ wc ...


1

The easiest way to do this is: $ for i in {1..3}; do cat inputfile$i>>outputfile; done


4

You can use '@', for example: $ files=( /tmp/a "/tmp/a file from windows" /tmp/myfile ) $ cat "${files[@]}" > newfile The '@' expands the entire contents of the array. It is similar to *except it will treat each element individuals whereas * will combine all elements as one.


0

This is trivial with zsh. % echo blah > a; echo asdf > b; echo harfjr > c; % filenames=(a b c d e) % print -l $filenames[1,3] a b c % cat $filenames[1,3] blah asdf harfjr % cat $filenames[1,3] > anewfile % cat anewfile blah asdf harfjr % somenum=2 % print -l $filenames[1,$somenum] a b % If the shell is actually bash or ksh uhhh dunno.


36

Both of those examples are useless uses of cat. Both are equivalent to wc < file1 > file2. There is no reason to use cat in this example, unless you are using cat file as a temporary stand-in for something that dynamically generates output.


0

Copy and paste (or put it at the end of your ~/.bashrc file) this bash function: logs() { zcat -f $(ls -rv1 "$1"*) | less; } Now you can type for example logs /var/log/syslog or logs /var/log/nginx/access.log to see all the syslog or nginx log messages from oldest to newest with less. You can then search something typing /something and hitting n for ...


3

All of the following commands are equivalent. They read the bytes of the CD /dev/sr0 and write them to a file called image.iso. cat /dev/sr0 >image.iso cat </dev/sr0 >image.iso tee </dev/sr0 >image.iso dd </dev/sr0 >image.iso dd if=/dev/cdrom of=image.iso pv </dev/sr0 >image.iso cp /dev/sr0 image.iso tail -c +1 /dev/sr0 ...


2

There are interesting facts in this case, specially these ones: I've just checked the output I got and provided (I used another disc this time, exactly, the Xubuntu 15.04 x64 setup disc), and with both procedures (dd and pv) the checksums are identical. I had the idea to, after doing the dd procedure, open the drive and close it with the same disc, and ...


2

SSH keys First of all, the best solution for you would be to create new ssh keypair and use this key to login to all your servers (or some, based on preferences). If you don't know how, you can find it many times here on stackexchange, but shortcut: ssh-keygen; ssh-copy-id your-host Basically you should set passphrase for your key, so you will log in ...


1

This method doesn't score highly in terms of correctness but should work in most cases: cat "$(ls -1t | head -n1)"


3

If you're going to just cat a newest file in one command you don't really need -l option. On Linux and Cygwin you can use -1 option and make parsing much easier: $ cat "$(ls -1rt | tail -n1)" -1 should be very portable, it's specified in POSIX. Also keep in mind that parsing ls output has its drawbacks. EDIT: As correctly noted in a comment by ...


0

Tried it on my system and: ~$ cat "$(ls -lrt | tail -n 1 | tr -s ' ' | cut -d ' ' -f9)" worked. ls -lrt Gives the files ordered by their modification time (-t) in reverse order (-r). tail -n 1 Gives you the last line of the output. tr -s '' Removes the repeat spaces in the line. cut -d ' ' -f9 Cuts the line on every space and gives you the ...


-1

Bash one-liner (provided your filenames do not contain spaces): cat $(ls -lrt | tail -1 | rev | cut -d" " -f1 | rev) Explanation: tail -1 # get last line of your ls rev # reverse characters order cut -d" " -f1 # take first field using space as a separator So the rev | cut -d" " -f1 | rev thing is a trick to be sure to get the last ...


0

grep . *.txt Matches all lines and also shows file names


0

As I understand it, piped processes all start more-or-less at the same time. Generally, the processes in a pipeline will read from stdin or write to stdout (or both), and completion of the I/O will dictate when the process ends. For processes that don't have any output (like touch) or any standard input (like cat when operating on a file), I would generally ...


2

Okay, considering that scr.txt file contains some text before executing command and scr6.txt doesn't exist yet: the command touch ~/scratches/scr6.txt | cat ~/scr.txt > ~/scratches/scr6.txt | cat /dev/null > ~/scr.txt Empty scr.txt file (cat /dev/null > ~/scr.txt) Overrides scr6.txt with contetns of scr.txt (nothing) (cat ~/scr.txt > ...


1

Breaking down each of the steps: touch ~/scratches/scr6.txt If file exists, updates the timestamp to now. If doesn't exist, creates it. cat ~/scr.txt > ~/scratches/scr6.txt Reads ~/scr.txt and writes the contents to ~scratches/scr6.txt cat /dev/null > ~/scr.txt Empties the ~/scr.txt file As mentioned in the comments, using "&&" (AND) ...


-1

In simple words: The touch command is the way to create new, empty files. It is also used to change the timestamps (i.e., dates and times of the most recent access and modification) on existing files and directories. In the first command it creates an empty file named scr6.txt. But in second command it create a file scr6.txt and writes all the contents of ...


0

To read and follow a file from the beginning until interrupted: tail -fn +1 file To demonstrate that, try this (assuming Bash with GNU Coreutils): (while true; do printf . >> /tmp/file; sleep 1; done)& tail -fn +1 /tmp/file # (Ctrl-C to interrupt, of course, or otherwise kill it.) kill % # Kills the while-loop. (Note: The +1f mentioned by ...


2

You are pretty close. Rather than cat you can use awk to skip the first line and print the remaining. find "${data_dir}/${river}/${gcm}/${scenario}" name \*.dat -exec awk 'NR > 1' {} + >> "${data_dir}/${river}/${gcm}/${scenario}.dat" This is a pretty empty awk script because it relies on the default behavior. No BEGIN or END and use the default ...


1

If all your files can be fit in to one awk invocation: find "/dir/folder" name "*.dat" -exec awk 'FNR == 1 && NR != 1 {next};1' {} +


0

tail allow you to skip given number of lines: find "/dir/folder" name "*.dat" -exec tail +2 {} + >> "/dir/folder/table.txt"


2

If the header is on one line, with GNU tail: find "/dir/folder" -name "*.dat" -exec tail -qn +2 {} + POSIXly, you'd need to run one tail per file: To preserve the header of the first file, GNUly: find "/dir/folder" -name "*.dat" -print0 | { IFS= read -rd '' first && cat "$first" && xargs -r0 tail -qn +2 }


3

With a BSD/GNU sed: find "/dir/folder" -name "*.dat" -exec sed -se1d {} + >> "/dir/folder/table.txt" ...which instructs to treat all input files separately, and for each to delete the 1st line. If the header isn't already in table.txt, you should first put it there, though: set -- /dir/folder/*.dat head -n1 <"$1" >>/dir/folder/table.txt ...


0

Commands like these may help man sshfs sshfs -h 2>&1 | more # or "less", if possible


2

People usually use a pager like less to read such a long output: sshfs -h | less On less type H to show help. Q to quit. Note that you might occasionally need 2>&1 to see also additional output from stderr. For sshfs -h it has such an output so you'd better do that like this: sshfs -h 2>&1 | less Besides using a pager, on Linux text ...



Top 50 recent answers are included