4 ms·

I wonder why -print0 / -0 isn't the default, as it seems that not using those options is the wrong way to do it. (Either that or why filenames can have spaces

by billpg 15y ago

I wonder why -print0 / -0 isn't the default, as it seems that not using those options is the wrong way to do it. (Either that or why filenames can have spaces or LFs in them.)

ams6110 15y ago
Historically, UNIX filenames almost never had spaces in them.
barrkel 15y ago
It's not the default because things like 'find | grep foo' wouldn't work as well: the output would appear all concatenated, as the terminal doesn't break lines on null characters. I wrote a utility I named print0, which simply converts line-oriented input into null-terminated output. Very useful for building pipelines of line-oriented utilities, where each line is a filename. It's quite common to have spaces in filenames (if nothing else, user files on NAS shares), and vanishingly rare to see newlines, so I find it to be a sensible tradeoff. Things like 'find | egrep | sed | print0 | xargs -0' work as you'd expect.
- premchai21 15y ago
  Would not « print0() { tr '\n' '\0'; } » work in most cases? Does your utility do something special to existing instances of \0? That's the only case I can imagine where the transformation is necessarily lossy and it's not clear what to do. I suppose in theory you could have newline normalization or something too.
  - barrkel 15y ago
    No, because that doesn't handle command-line arguments or '-' in the same way that cat does. It also doesn't handle the differences between DOS, Unix and Mac (\r, \n and \r\n) line endings properly. Finally, it's also slower than my 80-line C version.
- billpg 15y ago
  If filenames can contain LF characters, 'find | grep foo' is also wrong. (Interesting idea with print0, but I fear this is mere symptomatic relief, rather than actually fixing the problem.)
  - barrkel 15y ago
    As I already said, newlines[1] are vanishingly rare in filenames (most file manager UIs treat attempts at introducing a newline into the name as as committing the file rename), so I find it useful, so I wrote the utility, which only I use. How you figure my solution to my problem is only symptomatic treatment, with technical drawbacks I already mentioned but treat as acceptable, is beyond me. [1] As I mention in a cousin comment to this one, my utility handles all usual ASCII forms of newlines - \r, \n and \r\n (and \n\r for good measure).

by billpg 15y ago

I wonder why -print0 / -0 isn't the default, as it seems that not using those options is the wrong way to do it. (Either that or why filenames can have spaces or LFs in them.)

ams6110 15y ago

Historically, UNIX filenames almost never had spaces in them.

barrkel 15y ago

It's not the default because things like 'find | grep foo' wouldn't work as well: the output would appear all concatenated, as the terminal doesn't break lines on null characters. I wrote a utility I named print0, which simply converts line-oriented input into null-terminated output. Very useful for building pipelines of line-oriented utilities, where each line is a filename. It's quite common to have spaces in filenames (if nothing else, user files on NAS shares), and vanishingly rare to see newlines, so I find it to be a sensible tradeoff. Things like 'find | egrep | sed | print0 | xargs -0' work as you'd expect.

premchai21 15y ago
Would not « print0() { tr '\n' '\0'; } » work in most cases? Does your utility do something special to existing instances of \0? That's the only case I can imagine where the transformation is necessarily lossy and it's not clear what to do. I suppose in theory you could have newline normalization or something too.
- barrkel 15y ago
  No, because that doesn't handle command-line arguments or '-' in the same way that cat does. It also doesn't handle the differences between DOS, Unix and Mac (\r, \n and \r\n) line endings properly. Finally, it's also slower than my 80-line C version.
billpg 15y ago
If filenames can contain LF characters, 'find | grep foo' is also wrong. (Interesting idea with print0, but I fear this is mere symptomatic relief, rather than actually fixing the problem.)
- barrkel 15y ago
  As I already said, newlines[1] are vanishingly rare in filenames (most file manager UIs treat attempts at introducing a newline into the name as as committing the file rename), so I find it useful, so I wrote the utility, which only I use. How you figure my solution to my problem is only symptomatic treatment, with technical drawbacks I already mentioned but treat as acceptable, is beyond me. [1] As I mention in a cousin comment to this one, my utility handles all usual ASCII forms of newlines - \r, \n and \r\n (and \n\r for good measure).