Hot answers tagged


asciio I've used asciio for several years. Many of the diagrams on this site I've created using asciio. example vncviewer .-,( ),-. __ _ .-( )-. gateway vncserver [__]|=| ---->( internet )-------> __________ ------> ____ __ /::/|_| '-( ).-' [_...__...°] ...


POSIX requires this behavior, so it's not in any way unusual. From the POSIX vi manual: INPUT FILES See the INPUT FILES section of the ex command for a description of the input files supported by the vi command. Following the trail to the POSIX ex manual: INPUT FILES Input files shall be text files or files that would be text files ...


Indeed there is. It is called wc, originally for word count, I believe, but it can do lines, words, characters, bytes, and the longest line length. The -l option tells it to count lines. wc -l mytextfile


UNIX/Linux does not have the same early DOS / CP/M heritage that Windows does. So extensions are generally less significant to most UNIX utilities and tools. I usually use a command-line only environment. Extensions in such an environment under Linux aren't really significant except as a convenience to the operator or user. (I don't have enough ...


There is already a command for this: seq 100 104 will print these numbers on separate lines: 100 101 102 103 104 So just direct this output into a file: seq 100 104 > my_file.txt and seq 100 2 104 will print in increments of two, namely: 100, 102, 104


It is known as carriage return. If you're using vim you can enter insert mode and type CTRL-v CTRL-m. That ^M is the keyboard equivalent to \r. Inserting 0x0D in a hex editor will do the task. How to remove? You can remove it using the command perl -p -i -e "s/\r//g" filename. As the OP suggested in the comments of this answer here, you can even try a ...


This is the expected vi behavior. Your file has an incomplete last line so strictly speaking (i.e. according to the POSIX standard), it is not a text file but a binary file. vi which is a text file editor, not a binary one, gracefully fixes it when you save it. This allows other text file tools like wc, sed and the likes to provide the expected output. ...


If you ask file for just the mime-type you'll get many different ones like text/x-shellscript, and application/x-executable etc, but I imagine if you just check for the "text" part you should get good results. Eg (-b for no filename in output): file -b --mime-type filename | sed 's|/.*||'


Unlike Windows, in UNIX systems the filetype is not determined by the extension. The file extension is and was simply a visual indicator for humans. You can name a JPEG foo.c and open it in Gimp. Another contrast from Windows is that on UNIX systems you must use the entire filename, while Windows will often take care of it for you (e.g., running just ...


Another approach would be to use isutf8 from the moreutils collection. It exits with 0 if the file is valid UTF-8 or ASCII, or short circuits, prints an error message (silence with -q) and exits with 1 otherwise.


Have a look at artist-mode or picture-mode for Emacs (see also this screencast). You might also want to check out ditaa.


You have a lot of options! pdftotext from poppler has already been mentioned. There's a Haskell program called pdf2line which works well. calibre's ebook-convert commandline program (or calibre itself) is another option; it can convert PDF to plain text, or other ebook-format (RTF, ePub), in my opinion it generates better results than pdftotext, although ...


It should be pointed out that Mac OS X uses \n a.k.a linefeed (0x0A) now, just like all other *nix systems. Only Mac OS versions 9 and older used \r (CR). Reference: Wikipedia on newlines.


The problem, of course, is that you run grep on the big file 10,000 times. You should read both files only once. If you want to stay outside scripting languages, you can do it this way: Extract all numbers from file 1 and sort them Extract all numbers from file 2 and sort them Run comm on the sorted lists to get what's only on the second list Something ...


There is a difficult way and a much easier way. The difficult way is to use natural language parsing to give a probability that a given line is in English and discard such lines. The easier way is to take a list of English stop words and delete lines that contain elements from that list. If you wanted to decrease the chance of mis-categorizing a line, you ...


Switching the color is done through escape sequences embedded in the text. Invariably, programs issue ANSI escape sequences, because that's what virtually all terminals support nowadays. The escape sequence to switch the foreground color to red is \e[31m, where \e designates an escape character (octal 033, hexadecimal 1b, also known as ESC, ^[ and various ...


Try: grep -rl --null --include '*.txt' LINUX/UNIX . | xargs -0r cp -t /path/to/dest Because this command uses NUL-separation, it is safe for all file names including those with difficult names that include blanks, tabs, or even newlines. The above requires GNU cp. For BSD/OSX, try: grep -rl --null --include '*.txt' LINUX/UNIX . | xargs -0 sh -c 'cp "$@"...


All of: tr '[:lower:]' '[:upper:]' (don't forget the quotes, otherwise that won't work if there's a file called :, l, ... or r in the current directory) or: awk '{print toupper($0)}' or: dd conv=ucase are meant to convert characters to uppercase according to the rules defined in the current locale. However, even where locales use UTF-8 as the ...


More portably (POSIX features only): find . -type f -name '*.txt' -exec grep -q LINUX/UNIX \; -exec cp {} /path/to/dest \;


file tells you “Non-ISO extended-ASCII text” because it detects that this is: most likely a “text” file from the lack of control characters (byte values 0–31) other than line breaks; “extended-ASCII” because there are characters outside the ASCII range (byte values ≥128); “non-ISO” because there are characters in the 128–159 range (ISO 8859 reserves this ...


This answer is based on the awk answer posted by potong.. It is twice as fast as the comm method (on my system), for the same 6 million lines in main-file and 10 thousand keys... (now updated to use FNR,NR) Although awk is faster than your current system, and will give you and your computer(s) some breathing space, be aware that when data processing ...


There is tool source-highlight. Alias example: alias ccat="source-highlight --out-format=esc -o STDOUT -i"


If you like the heuristic used by GNU grep, you could use it: isbinary() { LC_MESSAGES=C grep -Hm1 '^' < "${1-$REPLY}" | grep -q '^Binary' } It searches for NUL bytes in the first buffer read from the file (a few kilo-bytes for a regular file, but could be a lot less for a pipe or socket or some devices like /dev/random). In UTF-8 locales, it also ...


Another option would be to use grep to find the number of times a pattern is matched: grep --regexp="$" --count /path/to/myfile.txt In this example, $ is an expression that evaluates to a new line (enter button is pressed) --count suppresses normal output of matches, and displays the number of times it was matched. The /path/to/myfile.txt is pretty ...


GNU grep has the following options: grep --only-matching --ignore-case --fixed-strings --file /usr/share/dict/british-english-insane /path/to/file.txt This outputs strings found one-per-line. Here /usr/share/dict/british-english-insane is a wordlist provided by the Debian package wbritish-insane.


tr can do that: tr -d \" < infile > outfile You could also use sed: sed 's/"//g' < infile > outfile


paste should be able to do the job. Here x.1 is the name of the file paste <(grep -E '^[[:alpha:]]+$' x.1) \ <(grep -E '^[[:digit:]]+$' x.1) \ <(grep -E '^[[:digit:]]+[.][[:digit:]]+$' x.1)


Yes, definitely do use a database. They're made exactly for tasks like this.

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