Tag Info

Hot answers tagged


In appearance, dd is a tool from an IBM operating system that's retained its foreign appearance (its parameter passing), which performs some very rarely-used functions (such as EBCDIC to ASCII conversions or endianness reversal… not a common need nowadays). I used to think that dd was faster for copying large blocks of data on the same disk (due to more ...


If the file(s) in question contain really lots of data sending the signal can actually get to cat before it finishes. What you really observe is the finite speed of your terminal - cat sends the data to the terminal and it takes some time for the terminal to display all of it. Remember, that usually it has to somehow redraw the whole output window for each ...


Although both commands allow you to view the content of a file, their original purposes are quite different. less extends the capabilities of more. The latter was created to view the content of a file one screenful at a time. less adds features such as backward movements and better memory management (no need to read the entire file before being able to see ...


You are looking for fold -w 80 -s text.txt -w tells the width of the text, where 80 is standard. -s tells to break at spaces, and not in words. This is the standard way, but there are other systems, which need "-c" instead of "-w".


I suggest the sed solution, but for the sake of completeness, awk 'NR >= 57890000 && NR <= 57890010' To cut out after the last line: awk 'NR < 57890000 { next } { print } NR == 57890010 { exit } Speed test: 100,000,000-line file generated by seq 100000000 > test.in Reading lines 50,000,000-50,000,010 Tests in no particular ...


#!/bin/bash if [[ "$#" -ne 1 ]]; then echo "Usage: $0 [INPUT FILE]" 1>&2 exit 1 fi cat "$1"


Passing the file through pygmentize-f terminal will attempt to detect the type from the filename and highlight it appropriately.


Whether such output can be exploited depends on the terminal program, and what that terminal does depending on escape codes that are being sent. I am not aware of terminal programs having such exploitable features, and the only problem now would be if there is an unknown buffer overflow or something like that, that could be exploited. With some older ...


This sounds like a job for paste: paste -d ' ' a.dat 1.dat Output: a b 1 2 c d 3 4


Most terminal emulators will send back some response, if they receive certain escape sequences (have a look at the xterm control sequences documentation). E.g., you can send \e[0c to a VT100-like emulator and it will send back the device attributes, something like \e[?1;2c (This is probably what Keith observed.) But these answers are not arbitrary strings. ...


The "definitive" answer is of course brought to you by The Useless Use of cat Award. The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process. Instantiating cat just so your code reads differently makes for just one more process and one more set ...


Try it with -f or --force: zcat -f -- * Since zcat is just a simple script that runs exec gzip -cd "$@" with long options that would translate to exec gzip --stdout --decompress "$@" and, as per the man gzip (emphasize mine): -f --force Force compression or decompression even if the file has multiple links or the corresponding file ...


You can use a while loop with process substitution: while read -r line do echo "$line" done < <(jobs) To read a multiline variable, a simple way is: printf %s "$var" | while IFS= read -r line do echo "$line" done Also, please don't call your variable jobs because that is a shell command and may cause confusion.


Just ask cat to concatenate that file with the stdin: cat cmd - | interactive


You cannot tell cat to use multiple standard out that way, the last redirection takes precedence so cat file1.txt >> file2.txt >> file1.txt is equivalent to >> file2.txt ; cat file1.txt >> file1.txt which obviously quickly fills the file system, given the fact the source file being the destination too grows indefinitely as long ...


It may be useful to explain how files work at the lowest level: A file is a stream of bytes, zero or more in length. A byte is 8 bits. Since there are 256 combinations of 8 bits, that means a byte is any number from 0 to 255. So every file is, at its lowest level, a big hunk of numbers ranging from 0 to 255. It is completely up to programs and users to ...


You can use: sed -e '/^;/d' php.ini


Maybe 'less -F file_to_read' is the option : it exits less if the window is sufficient to display all the file, and wait on the pager if it is not the case


zless It seems a pity about zcat, as libz has an API that supports reading from both compressed and uncompressed files transparently. But the manpage does say that zcat is equivalent to gunzip -c.


There are multiple ways to do this. The simplest is probably this: cat <<EOF | sh touch somefile echo foo > somefile EOF Another, which is nicer syntax in my opinion: ( cat <<EOF touch somefile echo foo > somefile EOF ) | sh This works as well, but without the subshell: { cat <<EOF touch somefile echo foo > somefile EOF } | ...


cat /dev/null > file.txt is a useless use of cat. Basically cat /dev/null simply results in cat outputting nothing. Yes it works, but it's frowned upon by many because it results in invoking an external process that is not necessary. It's one of those things that is common simply because it's common. Using just > file.txt will work on most shells, ...


I usually use cat when I need to type a command based on something in the file. cat is more convenient since you can see the file (if it's small) while you have access to the shell prompt. It also allows for pipe lining.


I usually use the column program for this, it's in a package called bsdmainutils on Debian: column -t foo Output: case elems meshing nlsys uniform 2350 0.076662 2.78 non-conformal 348 0.013332 0.55 scale 318 0.013333 0.44 smarter 504 0.016666 0.64 submodel 360 .009999 0.40 unstruct-quad 640 ...


Just add the -f option. $ echo foo | tee file | gzip > file.gz $ zcat file file.gz gzip: file: not in gzip format foo $ zcat -f file file.gz foo foo (use gzip -dcf instead of zcat -f if your zcat is not the GNU (or GNU-emulated like in modern BSDs) one and only knows about .Z files).


The first command here emulates the formatting you see in vim. It intelligently expands tabs to the equivalent number of spaces, based on a tab-STOP (ts) setting of every 4 columns. printf "ab\tcd\tde\n" |expand -t4 Output ab cd de To keep the tabs as tabs and have the tab STOP positions set to every 4th column, then you must change the way ...


Yes, it is possible. But not all formats support it. ffmpeg FAQ: A few multimedia containers (MPEG-1, MPEG-2 PS, DV) allow to join video files by merely concatenating them. When converting to RAW formats you also have a high chance that the files can be concatenated. ffmpeg -i input1.avi -qscale:v 1 intermediate1.mpg ffmpeg -i input2.avi -qscale:v 1 ...


@rush is right about using head + tail being more efficient for large files, but for small files (< 20 lines), some lines may be output twice. { head; tail;} < /path/to/file would be equally efficient, but wouldn't have the problem above.


Allocating the space for the output file first may improve the overall speed as the system won't have to update the allocation for every write. For instance, if on Linux: size=$({ find . -maxdepth 1 -type f -name 'input_file*' -printf '%s+'; echo 0;} | bc) fallocate -l "$size" out && find . -maxdepth 1 -type f -name 'input_file*' -print0 | sort ...


tail +1f file I tested it on Ubuntu with the LibreOffice source tarball while wget was downloading it: tail +1f libreoffice- | tar -tvJf - It also works on Solaris 10, RHEL3, AIX 5 and Busybox 1.22.1 in my Android phone (use tail +1 -f file with Busybox).


In Unix, most objects you can read and write - ordinary files, pipes, terminals, raw disk drives - are all made to resemble files. A program like cat reads from its standard input like this: n = read(0, buffer, 512); which asks for 512 bytes. n is the number of bytes actually read, or -1 if there's an error. If you did this repeatedly with an ordinary ...

Only top voted, non community-wiki answers of a minimum length are eligible