 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
During a commercial application suite installation:
"Can't access [insert db table name]. Consult
C:\Users\Administrator\Temp\{Long CLSID String}\{Another
CLSID}\Randomlygeneratedfilename.txt for details."
Of course, this is a popup window, so you can't cut and paste the string
anywhere.
WTF #2: there are many CLSID directories under Temp. Each with two
dozen randomly generated text files with various installation
information messages. Finding the one with the actual problem took over
an hour.
WTF #3: After talking with the app's customer support, it turns out that
the installer requires 8dot3name to be enabled on the drive because it
can't parse spaces in directory names, and can't use "C:\Program
files\Microsoft SQL Server\osql.exe" but needs
"C:\PROGRA~1\MICROS~1\osql.exe"
At this point, I need to point out that this is the installation of a 64
bit entreprise-grade application that came out two months ago, not some
legacy 16bit app designed for Windows 3.1
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/12/2012 15:38, Francois Labreque a écrit :
> During a commercial application suite installation:
>
> "Can't access [insert db table name]. Consult
> C:\Users\Administrator\Temp\{Long CLSID String}\{Another
> CLSID}\Randomlygeneratedfilename.txt for details."
>
> Of course, this is a popup window, so you can't cut and paste the string
> anywhere.
>
PrintScreen is your only friend. Then open "Paint", paste and save the
picture/desktop
> WTF #2: there are many CLSID directories under Temp. Each with two
> dozen randomly generated text files with various installation
> information messages. Finding the one with the actual problem took over
> an hour.
>
> WTF #3: After talking with the app's customer support, it turns out that
> the installer requires 8dot3name to be enabled on the drive because it
> can't parse spaces in directory names, and can't use "C:\Program
> files\Microsoft SQL Server\osql.exe" but needs
> "C:\PROGRA~1\MICROS~1\osql.exe"
>
> At this point, I need to point out that this is the installation of a 64
> bit entreprise-grade application that came out two months ago, not some
> legacy 16bit app designed for Windows 3.1
I want a refund.
Next question is: would that application be critical for business ?
If yes, pressure the provider to get a modern application supporting a
nearly twenty years old filenaming scheme (NTFS was released on July
1993 on Windows NT 3.1)
If no, revoke any maintenance contract with that firm, stating that not
supporting a twenty years old naming give the firm an outdated look and
broke the expected trust of professional.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] free fr> wrote:
> PrintScreen is your only friend. Then open "Paint", paste and save the
> picture/desktop
You left many important steps out. You have to print the picture, then
photograph it with a digital camera, read it into the computer and then
send it to yourself via email as a PDF.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 13 Dec 2012 10:07:42 -0500, Warp wrote:
> You left many important steps out. You have to print the picture, then
> photograph it with a digital camera, read it into the computer and then
> send it to yourself via email as a PDF.
You forgot the OCR conversion step.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/12/2012 17:49, Jim Henderson nous fit lire :
> On Thu, 13 Dec 2012 10:07:42 -0500, Warp wrote:
>
>> You left many important steps out. You have to print the picture, then
>> photograph it with a digital camera, read it into the computer and then
>> send it to yourself via email as a PDF.
>
> You forgot the OCR conversion step.
Where is the Fax ? There must be a Fax!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 13 Dec 2012 18:54:33 +0100, Le_Forgeron wrote:
> Le 13/12/2012 17:49, Jim Henderson nous fit lire :
>> On Thu, 13 Dec 2012 10:07:42 -0500, Warp wrote:
>>
>>> You left many important steps out. You have to print the picture, then
>>> photograph it with a digital camera, read it into the computer and
>>> then send it to yourself via email as a PDF.
>>
>> You forgot the OCR conversion step.
>
> Where is the Fax ? There must be a Fax!
Transmission via slow-scan TV, perhaps?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-12-13 09:55, Le_Forgeron a écrit :
> Le 13/12/2012 15:38, Francois Labreque a écrit :
>> During a commercial application suite installation:
>>
>> "Can't access [insert db table name]. Consult
>> C:\Users\Administrator\Temp\{Long CLSID String}\{Another
>> CLSID}\Randomlygeneratedfilename.txt for details."
>>
>> Of course, this is a popup window, so you can't cut and paste the string
>> anywhere.
>>
>
> PrintScreen is your only friend. Then open "Paint", paste and save the
> picture/desktop
>
Which doesn't help with pasting the error message in the vendor's online
problem tool.
>> WTF #2: there are many CLSID directories under Temp. Each with two
>> dozen randomly generated text files with various installation
>> information messages. Finding the one with the actual problem took over
>> an hour.
>>
>> WTF #3: After talking with the app's customer support, it turns out that
>> the installer requires 8dot3name to be enabled on the drive because it
>> can't parse spaces in directory names, and can't use "C:\Program
>> files\Microsoft SQL Server\osql.exe" but needs
>> "C:\PROGRA~1\MICROS~1\osql.exe"
>>
>> At this point, I need to point out that this is the installation of a 64
>> bit entreprise-grade application that came out two months ago, not some
>> legacy 16bit app designed for Windows 3.1
>
> I want a refund.
> Next question is: would that application be critical for business ?
> If yes, pressure the provider to get a modern application supporting a
> nearly twenty years old filenaming scheme (NTFS was released on July
> 1993 on Windows NT 3.1)
Of course it is critical for business, and it has to be up and running
for tomorrow.
They also say all over their documentation that they don't support space
in filenames under *nix, so it's probably more of a "we can't afford
programmers that are smart enough to deal with spaces." than "we can't
be bothered to fix our old install code".
> If no, revoke any maintenance contract with that firm, stating that not
> supporting a twenty years old naming give the firm an outdated look and
> broke the expected trust of professional.
>
>
I'd love to. Unfortunately, I don't have a say in the matter. The
decision to go with that product was made quite a few rungs above me on
the corporate ladder. Also, do you think Alcatel-Lucent gives a rat's
ass that I don't have a very high opinion of their software installation
package?
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/13/2012 01:07 PM, Jim Henderson wrote:
> On Thu, 13 Dec 2012 18:54:33 +0100, Le_Forgeron wrote:
>
>> Le 13/12/2012 17:49, Jim Henderson nous fit lire :
>>> On Thu, 13 Dec 2012 10:07:42 -0500, Warp wrote:
>>>
>>>> You left many important steps out. You have to print the picture, then
>>>> photograph it with a digital camera, read it into the computer and
>>>> then send it to yourself via email as a PDF.
>>>
>>> You forgot the OCR conversion step.
>>
>> Where is the Fax ? There must be a Fax!
>
> Transmission via slow-scan TV, perhaps?
>
> Jim
>
what about a couple of tin cans and a string ... or maybe morse coded
smoke signals. hey don't laugh if tech comes to a screeching halt that
talent /could/ be in high demand ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/12/2012 02:38 PM, Francois Labreque wrote:
> During a commercial application suite installation:
>
> "Can't access [insert db table name]. Consult
> C:\Users\Administrator\Temp\{Long CLSID String}\{Another
> CLSID}\Randomlygeneratedfilename.txt for details."
This is TRWTF. Everything else flows from here.
> Of course, this is a popup window, so you can't cut and paste the string
> anywhere.
Naturally.
> WTF #2: there are many CLSID directories under Temp. Each with two dozen
> randomly generated text files with various installation information
> messages. Finding the one with the actual problem took over an hour.
Yeah, but it's the temp folder. It's *expected* to contain lots of temp
files, all with random names. The problem is that this is where the log
file has been hidden, not somewhere you can actually *find* the thing.
> WTF #3: After talking with the app's customer support, it turns out that
> the installer requires 8dot3name to be enabled on the drive because it
> can't parse spaces in directory names, and can't use "C:\Program
> files\Microsoft SQL Server\osql.exe" but needs
> "C:\PROGRA~1\MICROS~1\osql.exe"
...this is also very wonky.
> At this point, I need to point out that this is the installation of a 64
> bit entreprise-grade application that came out two months ago, not some
> legacy 16bit app designed for Windows 3.1
I thought "enterprise-grade application" and "legacy 16-bit app" were
the same thing? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-12-13 15:22, Orchid Win7 v1 a écrit :
> On 13/12/2012 02:38 PM, Francois Labreque wrote:
>> At this point, I need to point out that this is the installation of a 64
>> bit entreprise-grade application that came out two months ago, not some
>> legacy 16bit app designed for Windows 3.1
>
> 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.
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 13 Dec 2012 14:21:04 -0500, James Holsenback wrote:
> what about a couple of tin cans and a string ... or maybe morse coded
> smoke signals. hey don't laugh if tech comes to a screeching halt that
> talent /could/ be in high demand ;-)
Oooh, good thought, going low-tech (or no-tech) hadn't come to mind. :)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-12-14 15:44, Orchid Win7 v1 a écrit :
>>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
