|
![](/i/fill.gif) |
Le 2012-12-17 22:00, Jim Henderson a écrit :
> 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
>
Yes, the solution is simple. Make sure that all shell commands using
filenames are properly double-quoted, and add a little more
argument-verification logic to the shell scripts.
But it requires going through hundreds of scripts (and in the Windows
version, additional batch files that start sh.exe with with the same
command line arguments).
If they didn't bother rewriting those shell scripts for Windows, and
insits on using a Unix-like environment to run the .sh scripts ,
something makes me think they aren't really willing to revisit all those
shell scripts in the first place.
In this cost-cutting world, I can't say I'm really surprised. I once
opened a ticket asking how we could run the app with a non-Administrator
user ID since getting an admin account with a non-expiring, shared
password is a big security no-no for my employer, and they replied "make
the user ID part of the 'Administrators' group".
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |