![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 2012-12-13 17:20, Jim Henderson a écrit :
> On Thu, 13 Dec 2012 15:38:57 -0500, Francois Labreque wrote:
>
>> That, or they're poorly done *nix ports where you have to run some sort
>> of "Unix shell for Windows" to run all the shell scripts that the
>> application uses.
>
> would have to be a pretty poor port of the Unix shell to not support long
> filenames.
>
> Jim
>
It's not the long file names per se, it's the spaces in the directory
names that causes the issue.
And you can't blame the port to windows, when it also requires that
there be no space in the application installation directory for Solaris,
Linux and HP-UX installations. Relying on the short file name is just a
means to get around the fact that there's a space in "Program Files" in
Windows, and you can't change that.
--
/*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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Thu, 13 Dec 2012 21:18:43 -0500, Francois Labreque wrote:
> Le 2012-12-13 17:20, Jim Henderson a écrit :
>> On Thu, 13 Dec 2012 15:38:57 -0500, Francois Labreque wrote:
>>
>>> That, or they're poorly done *nix ports where you have to run some
>>> sort of "Unix shell for Windows" to run all the shell scripts that the
>>> application uses.
>>
>> would have to be a pretty poor port of the Unix shell to not support
>> long filenames.
>>
>> Jim
>>
> It's not the long file names per se, it's the spaces in the directory
> names that causes the issue.
>
> And you can't blame the port to windows, when it also requires that
> there be no space in the application installation directory for Solaris,
> Linux and HP-UX installations. Relying on the short file name is just a
> means to get around the fact that there's a space in "Program Files" in
> Windows, and you can't change that.
Still not a very good port if it can't handle spaces and has to fall back
to 8.3 filenames.
Jim
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> I thought "enterprise-grade application" and "legacy 16-bit app" were
>> the same thing? ;-)
>
> That, or they're poorly done *nix ports where you have to run some sort
> of "Unix shell for Windows" to run all the shell scripts that the
> application uses.
Well, it could be worse... At least it doesn't require a physical VT100
in order to operate correctly. ;-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Le 2012-12-14 13:42, Jim Henderson a écrit :
> On Thu, 13 Dec 2012 21:18:43 -0500, Francois Labreque wrote:
>
>> Le 2012-12-13 17:20, Jim Henderson a écrit :
>>> On Thu, 13 Dec 2012 15:38:57 -0500, Francois Labreque wrote:
>>>
>>>> That, or they're poorly done *nix ports where you have to run some
>>>> sort of "Unix shell for Windows" to run all the shell scripts that the
>>>> application uses.
>>>
>>> would have to be a pretty poor port of the Unix shell to not support
>>> long filenames.
>>>
>>> Jim
>>>
>> It's not the long file names per se, it's the spaces in the directory
>> names that causes the issue.
>>
>> And you can't blame the port to windows, when it also requires that
>> there be no space in the application installation directory for Solaris,
>> Linux and HP-UX installations. Relying on the short file name is just a
>> means to get around the fact that there's a space in "Program Files" in
>> Windows, and you can't change that.
>
> Still not a very good port if it can't handle spaces and has to fall back
> to 8.3 filenames.
>
> Jim
>
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. ;)
--
/*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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> I thought "enterprise-grade application" and "legacy 16-bit app" were
>>> the same thing? ;-)
>>
>> That, or they're poorly done *nix ports where you have to run some sort
>> of "Unix shell for Windows" to run all the shell scripts that the
>> application uses.
>
> Well, it could be worse... At least it doesn't require a physical VT100
> in order to operate correctly. ;-)
No, but for the longest time it required Motif libraries for the GUI.
--
/*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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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.
--
/*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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |