On 12/17/2012 7:00 PM, Jim Henderson wrote:
> 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
>
Ah, well.. You see, they couldn't figure out how to write a shell script 
to check all the shell scripts for the problem, and fix it. lol

Post a reply to this message