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