Even smaller/easier if your shell can support (worked on above OSes): ckslash(){ if grep -q -s '^ID=msys2\?$' /etc/os-release; then printf //; else printf /; fi; } then in practice: rhash --path-separator=$(ckslash) --simple dir/file.txt

There is the possibility that a '//'-requiring OS also lacks an /etc/os-release file, but the chances seem...quite low? I hope?

windows via MSYS2: rhash --path-separator='/' = "RHash: path-separator is neither '/' nor '\': C:/msys64/" ----- linux CLI: rhash --path-separator='//' = "RHash: path-separator is neither '/' nor '\': //" . consensus: // is not always portable.

something else i see in the manpage. relevant? : "accept-line (Newline, Return) : Accept the line regardless of where the cursor is. If this line is non-empty, add it to the history list according to the state of the HISTCONTROL variable. If the line is a modified history line, then restore the history line to its original state."

how does this differ to revert-line in bash 3.2.57? (this version lacks revert-all-at-newline support) manpage says "revert-line (M-r) : Undo all changes made to this line. This is like executing the undo command enough times to return the line to its initial state."

i had a similar issue. i did a whole system update (which included linux-firmware and others) and it broke DNS resolution. i reverted back to previous package versions I had cached (thanks to pacman -U /var/cache/pacman/pkg/<package_name>-<package_version>-<arch‌​itecture>.pkg.tar.zs‌​t) and found out that for me, systemd/systemd-libs/systemd-sysvcompat were the culprits. reverted, rebooted, all OK again.

this works flawlessly on GNU sed 4.9. i was using \0 like OP and it didn't work. using \x0 instead is the solution.

does zpaq handle streamed data over pipes? i tried - as the input file and it didn't work. i'd like to use this with tar over pipes/with GNU tar -I flag.

both dead links

can also use dos2unix command line tool: dos2unix script.sh

thank you for the detailed answer. so in achieving my goal of a linux system as neutral & standardized as possible, is sed -i '/^#/! s/^/#/' /etc/locale.gen ; locale-gen ; localectl set-locale C an appropriate solution in regards to locales? (please see my above comment for further details). it looks ok to me with localectl status ; localectl list-locales ; locale -a but i don't know for certain.

my goal is to make a system as standardized as possible, and i learned LC_ALL=C sort orders strings by byte value which i prefer most. i still want UTF-8 support when doing something like making a tarball including e.g. japanese filenames: LC_ALL=C sort filelist.txt | tar -c --posix -T - -f out.tar ........ i wish to prevent mojibake filenames inside the tarball if i upload it online for others