New answers tagged

2

Another common remedy for this problem is to type Ctrl-VCtrl-O at the shell prompt. The first puts the shell into "literal" mode so that it won't modify the following character, which is the terminal reset command understood by almost all common terminal types. You might need to echo this instead, on some terminals.


3

That happened because the output you produced included codes that your terminal interface interpreted as control codes. This is normally resolved with either reset or stty sane.


9

I am ambitiously trying to translate a c++ code into bash for a myriad of reasons. Well yes. But maybe you should consider a very important reason for NOT doing it. Basically, "bash" / "sh" / "csh" / "ksh" and the like are not designed for processing binary data, and neither are most of the standard UNIX / LINUX utilities. You would be better off ...


19

Dealing with binary data at a low level in shell scripts is generally a bad idea. bash variables can't contain the byte 0. zsh is the only shell that can store that byte in its variables. In any case, command arguments and environment variables cannot contain those bytes as they are NUL delimited strings passed to the execve system call. Also note that: ...


6

From your question: copy the first 988 lines of the header If you are copying 988 lines, then it seems like a text file, not binary. However, your code seems to assume 988 bytes, not 988 lines, so I'll assume bytes is correct. hdr_988=`head -c 988 ${inputFile}` echo -n "${hdr_988}" > ${output_hdr} This part may not work. For one thing, any NUL ...


2

Unfortunately, to manipulate the content of a binary file, dd is pretty much the only tool in POSIX. Although most modern implementations of text processing tools (cat, sed, awk, …) can manipulate binary files, this is not required by POSIX: some older implementations do choke on null bytes, input not terminated by a newline, or invalid byte sequences in the ...


0

Part of the point of using dd at all is that the user gets to pick the block size it uses. If dd fails for too large block sizes, IMO it's the user's responsibility to try smaller block sizes. I could ask for a TB from dd in one block, but that doesn't mean I'll get it. If you want an exact number of bytes, this will be horrendously slow, but should work: ...


1

An encoding error according to mbrlen() also makes GNU grep 2.24 consider it as binary E.g.: export LC_CTYPE='en_US.UTF-8' printf 'a\x80' | grep 'a' because \x80 cannot be the first byte of an UTF-8 Unicode point: https://en.wikipedia.org/wiki/UTF-8#Description This is the only other possibility besides NUL. GNU grep source code interpretation that ...


3

Actually, the picture does not show any line-drawing characters. Running reset would (usually) help with that. But reset also repairs the terminal modes, somewhat more reliable than stty sane: If you use stty sane, that will fix problems with the terminal modes for echo and carriage return, but on Unix platforms (i.e., AIX, HPUX and Solaris) that sets ...


5

Terminals are controlled by escape sequences that are sent in-line with the character data to be displayed. That is how, for example, echo -e '\e[34m' will turn the text on many terminals blue. It's echoing some characters to the terminal—they happen to be an escape sequence which sets the foreground color. The terminal was messed up by being instructed to ...



Top 50 recent answers are included