Tag Info

New answers tagged

5

In addition to Gilles answer let me add, that you can always input non-printable characters in bash with Ctrl-v+key (Ctrl-v+Ctrl+4 in this case) and check the character code with $ printf '^\' | od -An -tu # input ^\ as C-v C-4 28 you get the decimal code of the character, which as you may check in man ascii corresponds to file separator (FS).


0

As can be seen, - also works: getline < "-" Or getline variable < "-"


21

Ctrl+4 sends ^\ Terminals send characters (or more precisely bytes), not keys. When a key that represents a printable character is pressed, the terminal sends that character to the application. Most function keys are encoded as escape sequences: sequences of characters that start with the character number 27. Some keychords of the form Ctrl+character, and a ...


13

wc will tell you what file it's working on if it's able. With the first one with the pipe it's reading from stdin, not a file, so does not report a filename. The second one, however, you're using process substitution which presents the output of the command as a file, which wc reports. It reports on the file descriptor it was given from which to read.


1

UPDATE: Given that find is the source of the data, I would use an array instead: readarray -t to_remove < <(find ...) number_of_files=${#toremove[@]} rm -i "${to_remove[@]}" If you are a pre-4 version of bash, use this loop to fill the array. while IFS= read -r fname; do to_remove+=("$fname") done < <(find ...) None of these work with ...


0

I figured it out. IFS=$'\n' for f in `echo "$to_remove"` ; do rm -ir "$f" done Short version: IFS=$'\n' rm -ir "$to_remove" Those two versions works as expected. Strange enough the following code doesn't work: IFS=$'\n' for f in "$to_remove" ; do rm -ir "$f" done Why?



Top 50 recent answers are included