On Mon, 17 Dec 2012 21:51:43 -0500, Francois Labreque wrote:

> Le 2012-12-17 11:56, Jim Henderson a écrit :
>> On Mon, 17 Dec 2012 10:02:32 -0500, Francois Labreque wrote:
>>
>>> One could say that it's a true-to-the-orignal port of a not-very-good
>>> application if the Unix orignal can't handle spaces either. ;)
>>
>> Yeah, but that'd not be a modern app, which is what I assume we're
>> talking about here - a port of a modern POSIX app that can't handle
>> long filenames or spaces isn't very "modern".
>>
>> Jim
>>
> The app might have more than 15 years of existence , but the latest
> version came out at the end of november.
> 
> And it has no problems with long file names under any OS, as long as
> that long file name doesn't have spaces in it.
> 
> It's much easier to write in the release notes not to put spaces than to
> go through the hundread or so shell scripts that the app calls in the
> back end and make sure all the "cd $FOO" are properly doublequoted.
> 
> In *nix, it's usually is no big deal since there's no space in /opt or
> /usr/local, but in Windows, there is one in "Progam Files", so one is
> left with either installing in a non-standard place, or forcing
> shortnames to work around the space.

I've never run across a modern POSIX program that had trouble with 
spaces.  But I've only been doing UNIX since 1983 or so (first experience 
was in the sixth grade on some old PDP equipment that I'm pretty sure was 
running some form of UNIX - I remember it had a bash shell) and Linux 
since about 1989.

Seems like a simple thing to address.

Jim

Post a reply to this message