On 7/6/07, John Summerfield <[EMAIL PROTECTED]> wrote:
inode0 wrote:
> On 7/6/07, John Summerfield <[EMAIL PROTECTED]> wrote:
>> Seems to me the best fix is for Red Hat to do it. Red Hat's broken
>> compatibility with earlier releases, and whatever individual users do,
>> it's still going to bite those unprepared.
>
> The best fix is for people writing ksh scripts to stop relying on
> system dependent behavior to be portable because it isn't.
If that were likely to happen, the problem would not exist. Probably,
most people who write to ksh don't know what the rules are: I personally
write for bash, and I know much that does work, but I have been caught
on bash bugs before. For example, prior to bash 2 this worked:
{ echo a;echo b;echo c }
The error isn't obviously an error, and I only know it's wrong because
the authors of bash say so.
Sure, agreed. People write bad scripts. Red Hat won't have time to do
anything else if it is their responsibility to hack the OS or other
people's applications so all those bad scripts work as the authors
wanted them to work.
>> If RH fixes it, then it's done for everyone forever.
>
> How do you want Red Hat to fix it? By keeping their own version of ksh
> which masks the buggy scripts? By sticking a link to /bin/echo
> somewhere else where ksh happens to see it now (although this appears
> to depend on what one has in the PATH variable)?
It's a useful workaround.
It doesn't seem to me to depend on what's in PATH: it certainly did not
test everywhere.
Add /bin to the front of your PATH and see what happens. It
dramatically changes the behavior on F7.
Possibly, using PATH fully is the correct behaviour.
By what standard are you defining "correct behavior?" The way you
think it should work?
> Red Hat hiding portability problems in other people's code doesn't fix
> the problem for everyone forever. They will try to run the code
> somewhere else and it will fail again and be another vendor's problem
> to fix.
While ever there is more than one implementation of a complex standard,
or there is some ambiguity, portability problems will arise. If you
expect your web server's documents to be someplace under /var, you will
be surprised if you try SLED. If you think MySQL implements SQL, you
will be surprised when you try it in Postgresql.
Sure, agreed. But in those cases also it isn't Red Hat's job to define
undefined behavior so that poorly written things work as the authors
of those poorly written things expect them to work.
> Red Hat putting a bandaid on this for Red Hat customers might be
> welcomed by those customers but the scripts need to be fixed for this
> to be fixed for everyone forever.
In your dreams. Through ignorance, through misunderstanding, through
ambiguity, incompatibilities will continue to arise: it's the way we are.
Heck, tell an American he's penurious, he'll probably deck you. Tell an
Australian he's penurious, he'll likely agree with you. Different folks
see things differently.
Heh, those ("for everyone forever") were your words that I aped for effect.
John
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
