On 20/09/13 14:55, Lev Lafayette wrote:
On Fri, September 20, 2013 2:05 pm, Jeremy Visser wrote:
Or, we could all just not be dicks, accept the fact that some filenames have spaces (because, shock horror, people *like* spaces), and deal with it like proper engineers should.
Yeah, some problems are hard. I get that. That doesn’t impact on what should/shouldn’t be solved.
Sounds like you're volunteering Jeremy. I look forward to seeing the solution! :)
Solution to what? I’m arguing *for* the status quo, not against it. I’m arguing against the arguments against the status quo. That makes sense, right?
On Fri, Sep 20, 2013 at 04:38:53PM +1000, Jeremy Visser wrote:
Solution to what? I?m arguing *for* the status quo, not against it.
I?m arguing against the arguments against the status quo. That makes sense, right?
the status quo is that users who create filenames with spaces on unix systems deserve a severe and vicious larting. -print0 is for when it's inconvenient to find your 2x4 craig -- craig sanders <cas@taz.net.au> BOFH excuse #56: Electricians made popcorn in the power supply
Craig Sanders <cas@taz.net.au> writes:
On Fri, Sep 20, 2013 at 04:38:53PM +1000, Jeremy Visser wrote:
Solution to what? I'm arguing *for* the status quo, not against it. I'm arguing against the arguments against the status quo. That makes sense, right?
the status quo is that users who create filenames with spaces on unix systems deserve a severe and vicious larting.
-print0 is for when it's inconvenient to find your 2x4
IMO -- apart from make (for hysterical raisins) -- unix processes should deal with paths that contain arbitrary bytes. Not because it's nice for users, but because it's defensive programming against injection attacks. Yes, -print0 is slightly annoying, and I don't bother when writing one-liners to operate on my personal equipment. But if your stuff is going to be exposed to user input, HTFU and use -print0 and friends.
On Fri, Sep 20, 2013 at 06:17:58PM +1000, Trent W. Buck wrote:
-print0 is for when it's inconvenient to find your 2x4
IMO -- apart from make (for hysterical raisins) -- unix processes should deal with paths that contain arbitrary bytes. Not because it's nice for users, but because it's defensive programming against injection attacks.
yes, i know. i use -print0 and friends all the time. spaces and other incovenient characters are common enough that doing so is essential. it was a joke. an obvious one, i thought. the mention of a 2x4 was a bit of a giveaway. craig -- craig sanders <cas@taz.net.au> BOFH excuse #23: improperly oriented keyboard
On Fri, Sep 20, 2013 at 4:42 PM, Craig Sanders <cas@taz.net.au> wrote:
On Fri, Sep 20, 2013 at 04:38:53PM +1000, Jeremy Visser wrote:
Solution to what? I?m arguing *for* the status quo, not against it.
I?m arguing against the arguments against the status quo. That makes sense, right?
the status quo is that users who create filenames with spaces on unix systems deserve a severe and vicious larting.
Then I welcome your patch to your filesystem of choice that restricts filenames to not include spaces. Personally, I think rants like this about what should and shouldn't be in filenames are pretty immature. If the filename is permitted, then the character in question is fine. brett@capsid:~$ stat fo* File: ‘foo\nbar’ Size: 3 Blocks: 8 IO Block: 4096 regular file Device: fc01h/64513d Inode: 57920 Links: 1 Access: (0664/-rw-rw-r--) Uid: ( 1000/ brett) Gid: ( 1000/ brett) Access: 2013-09-20 19:34:39.291570671 +1000 Modify: 2013-09-20 19:34:39.291570671 +1000 Change: 2013-09-20 19:34:39.291570671 +1000 Birth: - Look, a newline in a filename, I bet you're frothing at the mouth. Yet it's fine. XFS allowed me to create it happily. And most programs are happy with it. Because they're not so poorly written as to make stupid assumptions about the properties of a filename. If your program is so badly coded that it mandates that certain characters can't be in a filename, then I suggest it's that author that requires larting, not the user. / Brett
participants (4)
-
Brett Pemberton -
Craig Sanders -
Jeremy Visser -
trentbuck＠gmail.com