----- Original Message -----
From: "Stephen M. Dunn" <stephen@stevedunn.ca>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Wednesday, September 19, 2007 6:20 PM
Subject: Re: cannot erase large file on osr6
> In article <JoKHx1.24ss@wjv.com> bv@wjv.com writes:
> $This suggestion is similar to what happens when Linux distros
> $change their options and breaks shell scripts which use
> $commands that have worked for a long time - and all of a sudden
> $break with nag messages, warning messages, and other discouraging
> $items.
>
> Previous shell scripts have used a version of rm that worked for a
> long time - if you asked it to delete a file, it deleted it. The file
> could be any size, from zero to whatever the largest file supported by
> the OS was, and rm would simply delete it. Now, that no longer works.
> Previous shell scripts which could rely on "rm foo" being able to
> delete foo (subject to permissions, of course) regardless of how large
> or small foo was are already broken by the change in functionality.
>
> Anyway, then, let's reverse it. If you want a version of rm
> that works properly (i.e. it deletes any file you ask it to), use
> rm. If you want a version that will work properly on small files
> and refuse to delete large files (i.e. works differently than the
> way rm has worked for the last couple of decades) then add a
> command-line option that makes it work like this. That will
> satisfy your requirement below:
>
> $No all things work from the command line and you don't want to
> $change operations of something that worked so well for a long
> $time that may break existing scripts admins may have written.
>
> All of the existing command-line options that worked so well
> for a long time still exist, and still work exactly the way they've
> worked so well for a long time. As opposed to the OSR6 way, in
> which if you want a version of rm that works the way rm has worked
> in every previous version of OpenServer, SCO Unix, or SCO Xenix
> for the last two decades plus, you have to use the version that
> your path, by default, *doesn't* give you.
>
> $And why not just move rm to rm-orig on your system and symlink
> $the u95 version to 'rm' ?
>
> Why should I have to do this in order to have a version of rm
> that, like the versions of rm on every previous version of OpenServer,
> SCO Unix, or SCO Xenix, will delete any file I ask it to? The
> thing should work normally right out of the box, without me having to
> fiddle with stuff like this.
>
> Plus, your suggestion will quite possibly result in rm suddenly
> breaking if I install a patch or update; if that patch or update
> puts a new verson of the "I only like small files" rm back in the
> usual place, I have to fix it again. And again and again, if future
> updates include this. I'm not sure if OSR6 has the same verification
> code (running every week and/or every time I install an update)
> that OSR5 had, but your suggestion will also result in warnings
> from that code.
>
> No, the thing should just work properly from the start. It
> should delete any file to which you have sufficient access.
There is obviously an argument for defulting the system to use utils that
work fully.
But this is SCO, not Linux or Windows or Sony PlayStation. The overwhelming
majority of SCO users are more concerned with backwards compatibility, down
to the tiniest detail, above _all_ else. And because of the way and the
contexts in which they use the OS, they are not wrong.
If you are a VAR with an app that currently works on on OSR5, then that app
does not involve any such thing as a file over 2G in size. It does not
matter if "rm" or anything else can handle +2G file. It _does_ matter that
all the zillion features of the system, such as "rm" behave exactly the same
as the previous version. This means such things as command line options must
all be the same, they must all behave exactly the same, fail or work under
exactly the same conditions, error & other messages must all be the same and
occur or not, under the same conditions.
If the large-file aware "rm" is a new binary generated from new source
unrelated from the old one, (which it is), then in the specific case of
SCO, it probably does make more sense to default the system to using the old
binary instead of the new one, even though that constitutes a system that is
basically broken from most perspectives.
Not all OS's are used by the same people with the same needs and the same
expectations and the same tolerance for the same types of problems or
unexpected behaviour. You would rather have an rm that handles all files by
default, and apparently don't care if it bahaves differently from the
preceding 15 years. Fine, that's you. you are not the world. What is obvious
to you is just as obviously backwards to someone else, and they are not
wrong or illogical just because they are not a clone of you. Your idea of
"expected behaviour" simply differs from that of most SCO users. You are not
wrong, neither are they. But since SCO's customers are SCO users, then the
most correct and logical thing for SCO to do is to meet SCO users
expectations, not yours or more generally Linux users expectations.
Most existing OSR5 users could care less about a 2G file, but if rm, buried
in some script or buried in a system() command in some app, suddenly
developed some subtle change in behaviour like, producing a output that
doesn't exactly match what his script/app knows how to parse, or worse, has
command line options that don't do the same things as before, that could
cost him a _lot_ of time and grief and maybe even one or more customers,
both for direct and indirect reasons.
The fact that rm is a basic sort of util that mostly does the same thing on
every OS, and that most people only use the most basic command line options
that almost every OS has and that do the same things on every OS, and that
most people probably don't parse the output of rm, nor be affected much if
it started generating output in some situation where it used to be silent,
or vice/versa, none of that is a legitimate reason for replacing rm with a
new and improved one. All those probablys and mosts don't add up to
anything.
Also, remember that this isn't about "rm" this is about a zillion things
throughout the system. It's all true for rm only because it's true for
everything, rm is simply no exception.
Users that want to make more full use of OSR6's new features, and are OK
with dealing with some breakage along the way, are free to switch their
system to default to use all the new utils instead of the old ones by just
placing the u95 bins in their PATH ahead of the other bin directories. or
copy the binaries right into the normal paths to handle commands that
specify the full path.
--
Brian K. White
brian@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!