shurr@cbnews.att.com (Larry A. Shurr) (01/19/91)
Sound FX: bridge alarm sound Computer: Red alert! Red alert! Capt. Smirk: What is it! Lt. Lulu: Captain! Sensors detect approaching flame war! Mr. Block: Correction, Captain. Mr. Lulu's sensors are misinterpreting a somewhat heated exchange as a full-fledged flame war. Capt. Smirk: Any danger? Mr. Block: In all probability, no sir. Such exchanges have been known to escalate in intensity, thus possibly becoming a flame war, but they frequently do not, "More light than heat" I believe is the coloquial phrase. Outbursts of this type are actually quite common in this region of space. Capt. Smirk: What do you mean? Mr. Block: We are currently traversing an unmoderated source quadrant. When new, non-source matter is occasionally introduced, various reactions ensue. Without moderation, there is always some instability. One could wish for low-key reac- tions in such circumstances, but that is generally not the case. Capt. Smirk: Any precautions needed? Mr. Block: Unless Engineer Shot has any suggestions... Mr. Shot: Get on with 'ee! Ayem an engineer, not a moderator! Dr. Decoy: Hey! That's my line! Mr. Block: ... It might be wise to activate the Korbomite device. Capt. Smirk: Very well. If you are all quite ready... proceed Mr. Lulu. Lt. Lulu: Aye, Captain! Pressing 'K' key... NOW! Sound FX: Poof! -- Larry A. Shurr (cbnmva!las@att.ATT.COM or att!cbnmva!las) The end of the world has been delayed due to a shortage of trumpet players. (The above reflects my opinions, not those of AGS or AT&T, but you knew that.)
tneff@bfmny0.BFM.COM (Tom Neff) (01/19/91)
Of course patches are source, and should be posted to source newsgroups. Why do patch posters get undeserved flames from SANP's?** Because once you legitimize the practice of canned poster harrassment, the barn door is open and any idiot can get into the act. ________ ** SANP = Self Appointed Network Policeperson
guido@cwi.nl (Guido van Rossum) (01/19/91)
OK, hey, I surrender! I won't ever post non-source to alt.sources again! But don't send me any more flames. How many self-appointed policemen does alt.sources have? Are there any other rules I should be aware of? I am about to post half a megabyte of source; wouldn't want to be flamed for *that*... --Guido
src@scuzzy.in-berlin.de (Heiko Blume) (01/20/91)
tchrist@convex.COM (Tom Christiansen) writes: >Oh well. I thought that it needed being said, and in public so that folks >who didn't know better and might sometime go off and post non-source would >learn that this wasn't the best idea. sigh, what is "source code" ?! i got a somewhat flamy mail in reply to my bash patches indicating that i should only post source to alt.sources, and that a.s.d is for comments and requests... i suspect that it's a prepared file that the person (didn't bother to save the mail) sends to anyone who, in his opinion, hasn't posted "source". so let's discuss: are patches to a generally available program "source code" ? if not, where the f*ck shall one post patches? alt.test? junk? of course, since this is *alt*.sources i couldn't feel less 'guilty' of posting "non-source" to alt.sources. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
tchrist@convex.COM (Tom Christiansen) (01/20/91)
From the keyboard of src@scuzzy.in-berlin.de (Heiko Blume):
:tchrist@convex.COM (Tom Christiansen) writes:
:
:>Oh well. I thought that it needed being said, and in public so that folks
:>who didn't know better and might sometime go off and post non-source would
:>learn that this wasn't the best idea.
:
:sigh, what is "source code" ?! i got a somewhat flamy mail
:in reply to my bash patches indicating that i should only
:post source to alt.sources, and that a.s.d is for comments
:and requests... i suspect that it's a prepared file that
:the person (didn't bother to save the mail) sends to anyone
:who, in his opinion, hasn't posted "source".
I'm sure glad it wasn't me.
:so let's discuss: are patches to a generally available program "source code" ?
I asked myself the same question when posting a recent patch. There
exists an 'alt.sources.patches', but it doesn't seem to get used very
much. In the comp hierarchy, we have a comp.sources.bugs, which does see
a fair amount of traffic. IMHO, it's ok to post patches to alt.sources,
since they are themselves source. Perhaps the thought police will explain
wherein I err in opining thus.
I still think that alt.sources is a sufficiently useful group as to merit
promotion into the comp hierarchy to promote a wider distribution.
--tom
--
"Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now
he can finally have the whole O/S built-in to his editor like he
always wanted!" --me (Tom Christiansen <tchrist@convex.com>)emv@ox.com (Ed Vielmetti) (01/20/91)
In article <1991Jan19.162832.10983@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes:
so let's discuss: are patches to a generally available program "source code" ?
usually. depends if they are "official patches" (yes) or "unofficial
patches" (not usually).
if not, where the f*ck shall one post patches? alt.test? junk?
comp.sources.bugs often gets patches. alt.sources sometimes gets
patches. a few sites around the world have an "alt.sources.patches"
group which hardly ever gets patches, though it's the right name more
or less.
--Ederic@sactoh0.SAC.CA.US (Eric J. Nihill) (01/21/91)
Cc: src@scuzzy.in-berlin.de
Dear Scuzzy:
In the course of trying to archive comp.sources, it is necessary
currently to write down the article number, as to seperate it
from the trash. Unfortunatly, in writing down the numbers to
save and the numbers to forget, your article number was copied
down incorrectly. That is why you received the letter.
It is obivious by your emotional response that this caused
you a great deal of emotional stress. I am sorry that you had
to endure this overwhelming burden and needed to express it to
the world.
I apoligize for putting you through this emotional crisis, and
assure you that I will not subject you to this duress again.
I will post this letter to alt.sources.d, to let the rest of the
world know that your overly emotional response was justifiable.
I can only hope that this will repair your tarnished image in
the eyes of others and mend the damaged ego.
Yours truly, Eric
--
To think that some | eric@sactoh0.SAC.CA.US
people get paid to do | ames!pacbell!sactoh0!eric
this....! | ucbvax!csusac!sactoh0!eric
root@sactoh0.sac.ca.us | ( A Home For Unwanted 3B's )jpn@genrad.com (John P. Nelson) (01/22/91)
>so let's discuss: are patches to a generally available program "source code" ? YES! Emphatically YES! > i suspect that it's a prepared file that >the person (didn't bother to save the mail) sends to anyone >who, in his opinion, hasn't posted "source". Any self-appointed net-policeman who is flaming people who have posted a valid source code (and patches are most definitely source code), should in turn, be flamed to a crisp. john nelson uucp: {decvax,mit-eddie}!genrad!jpn domain: jpn@genrad.com
src@scuzzy.in-berlin.de (Heiko Blume) (01/22/91)
emv@ox.com (Ed Vielmetti) writes: > if not, where the f*ck shall one post patches? alt.test? junk? >comp.sources.bugs often gets patches. yes, but that's a discussion group, mainly, and then you'll get bitched at because you posted source to a non-source group :-) also c.s.b doesn't get archived at uunet etc. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
src@scuzzy.in-berlin.de (Heiko Blume) (01/22/91)
eric@sactoh0.SAC.CA.US (Eric J. Nihill) writes: >I can only hope that this will repair your tarnished image in >the eyes of others and mend the damaged ego. and i hope you'll be much more careful about sending people inappropriate mails in the future. that's counter productive. otherwise you might get anNihillAted sometime, by people who get angry easily (certainly not me). nomen est omen ;-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/24/91)
In article <1991Jan17.224403.16050@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > And just so I am not zapped for not practicing what I preach, here's > a little script that points out executables in your path whose names > occur more than once, you know, like /bin/mail and /usr/ucb/mail. [ 36-line perl script, including 28 lines of real code ] Here's a little script that points out executables in your path whose names occur more than once, you know, like /bin/mail and /usr/ucb/mail. (N.B. This isn't meant as a clone of Tom's script; it doesn't bother printing where the conflicts are, for example.) Just so Tom doesn't accuse me of cheating, I spread everything out onto separate lines, so this is an 11-line script, including 7 lines of real code. Now what is easier to maintain: a simple 7-line shell script, or a 28-line perl script? Moral: Use the right tools for the right job. (And don't pretend that adding a trivial script to an alt.sources.d posting makes it appropriate for alt.sources.) #!/bin/sh # omit L if no symbolic links # replace sort -u with sort | uniq if sort doesn't support -u ls -ilFL `echo "$PATH" | tr : '\012'` \ | sed -n 's/\*$//p' \ | rev \ | sort -u \ | sed 's/ .*//' \ | uniq -d \ | rev ---Dan
tchrist@convex.COM (Tom Christiansen) (01/25/91)
From the keyboard of brnstnd@kramden.acf.nyu.edu (Dan Bernstein): :Here's a little script that points out executables in your path whose :names occur more than once, you know, like /bin/mail and /usr/ucb/mail. :(N.B. This isn't meant as a clone of Tom's script; it doesn't bother :printing where the conflicts are, for example.) Just so Tom doesn't :accuse me of cheating, I spread everything out onto separate lines, so :this is an 11-line script, including 7 lines of real code. :Now what is easier to maintain: a simple 7-line shell script, or a :28-line perl script? You're comparing apples with windmills. Your script doesn't at all do the same thing. Feel free to try again. --tom -- "Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now he can finally have the whole O/S built-in to his editor like he always wanted!" --me (Tom Christiansen <tchrist@convex.com>)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/26/91)
In article <1991Jan25.090627.14302@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > :Now what is easier to maintain: a simple 7-line shell script, or a > :28-line perl script? > You're comparing apples with windmills. Your script doesn't at > all do the same thing. Yes, it does, except for the difference I noted (and a few arbitrary limitations that will never come up in practice). For example, on this machine, /bin/cat and /usr/bin/cat are the same file. Your perl script takes several lines of tests to make sure that it doesn't report cat. My script takes one line to do the same thing. On this machine, /bin/mail and /usr/ucb/mail are quite different. So your script reports them. Mine does too. The difference is that mine just says ``mail'' while yours also points out where the conflicting versions are. Naturally, I think that it's the job of ``which'' to do the latter, but it's just a 2-line change to the shell script if you care. Why are you dodging the question, Tom? Does it hurt your ego to see that something is much more easily done with standard tools than with perl? ---Dan
tchrist@convex.COM (Tom Christiansen) (01/26/91)
From the keyboard of brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
:In article <1991Jan25.090627.14302@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
:> :Now what is easier to maintain: a simple 7-line shell script, or a
:> :28-line perl script?
:> You're comparing apples with windmills. Your script doesn't at
:> all do the same thing.
:
:Yes, it does, except for the difference I noted (and a few arbitrary
:limitations that will never come up in practice).
:
:For example, on this machine, /bin/cat and /usr/bin/cat are the same
:file. Your perl script takes several lines of tests to make sure that it
:doesn't report cat. My script takes one line to do the same thing.
:
:On this machine, /bin/mail and /usr/ucb/mail are quite different. So
:your script reports them. Mine does too. The difference is that mine
:just says ``mail'' while yours also points out where the conflicting
:versions are. Naturally, I think that it's the job of ``which'' to do
:the latter, but it's just a 2-line change to the shell script if you
:care.
You assume you can tell me what I wrote my script to do, and then you go
on to redefine this. For this they invented the word arrogant, and then
tacked ignorant on to the end of it. I wrote it to give the output it
gives. The problem was to list the full path names of all names in
collision. Nothing less than this solves the problem.
--tom
--
"Hey, did you hear Stallman has replaced /vmunix with /vmunix.el? Now
he can finally have the whole O/S built-in to his editor like he
always wanted!" --me (Tom Christiansen <tchrist@convex.com>)brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/27/91)
Well, ain't this cute. Tom posts 28 lines of Perl to do FOO. I post 7 lines of sh+tools to do essentially the same thing, and I mention that it doesn't do trivial feature BAR. Tom says ``Your script doesn't at all do the same thing''; when pressed, he admits that he's only talking about BAR. Fine, here's a simple sh script to do FOO + BAR (modulo the minor caveats from before). It's essentially the same as the previous script, with a ``which'' loop in the style people seem to like. Sheesh. Face it, Tom, it takes twenty words of sh code (including | tokens) to combine six *appropriate* tools to list repeated names in $PATH. It takes much, much more than that to solve the problem in Perl without outside help. The only rational conclusion is that Perl is the wrong tool for the job. #!/bin/sh dirs=`echo "$PATH" | tr : '\012'` # List all files in path. Look back to front. Sort, removing duplicates. # Remove all ls info except filename, and select executables. Find reps. for i in `ls -ilFL $dirs | rev | sort -u \ | sed -n -e 's/ .*//' -e 's/^\*//p' | uniq -d | rev`; do # Print the repeats, in some stilted format that tchrist@convex.com wants. # Yes, this is unnecessary duplication of a function already available in # other programs, and it reduces the usefulness of this interface. Oh, well. echo -n "$i: " for j in $dirs; do test -f "$j/$i" && echo -n "$j/$i " done echo '' done > You assume you can tell me what I wrote my script to do, and then you go > on to redefine this. For this they invented the word arrogant, and then > tacked ignorant on to the end of it. Oh, fgs. You described your script as doing FOO, and I described mine as doing FOO. At every stage in this discussion I have been very careful to point out whose script does what, to note the differences (like BAR), etc. I never tried to redefine what yours did, but you said that mine didn't ``at all do the same thing'' as yours---an obviously false statement, intended only to put me down because you know you've lost on technical merits. Take a step back, Tom: who's being arrogant here? > The problem was to list the full path names of all names in > collision. I don't see ``full path names'' in the original problem statement. > Nothing less than this solves the problem. Sure, Tom, whatever you say. ---Dan
dik@cwi.nl (Dik T. Winter) (01/27/91)
Now I thought that the discussion was about a script/program that acted which- like and pointed to duplicates. Dan moves on to another field giving a script that gives all duplicate executables in your path; it does not look at the arguments you give. I have a few complaints (and than thinking that Dan complained that the perl script was not portable!). A number of these already apply to Dan's one- liners (did you program APL originally?). In article <1943:Jan2619:34:3591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: ... > for i in `ls -ilFL $dirs | Complaint 1: ls complains about non existing directories that I have in my path. I know I have them, my base path is identical on all machines I have access to. So this should be changed to: for i in `(ls -ilFL $dirs 2>/dev/null) | (And as noted already the -L flag is illegal on some (UNIX) systems.) > rev | Complaint 2: some of the (UNIX) systems I have access to tell me: rev not found. What do I do now? Write a csh alias to do rev? > sort -u \ Looks correct. > | sed -n -e 's/ .*//' -e 's/^\*//p' | Complaint 3: Mmm. What with a filename that ends in an asterisk? And files with embedded blanks? (And do not come with the answer that people should not have files with such names, because people do have them. Just like they have '.' in their path. Be robust, just as in another thread: There should be no limits.) > uniq -d | rev`; do Looks correct (except for rev of course). > echo -n "$i: " Complaint 4: On some (UNIX) systems this will not echo what you want. But than you have already a problem with rev of course. > for j in $dirs; do Correct again. > test -f "$j/$i" && echo -n "$j/$i " Same complaint about echo. > done Correct. > echo '' Why those quotes? > done Correct again. Score: 8 lines of code, 3 correct. Dan, Dan, you ought to do better. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
karl@sugar.hackercorp.com (Karl Lehenbauer) (01/28/91)
In article <24078:Jan2516:52:2591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Why are you dodging the question, Tom? Does it hurt your ego to see that >something is much more easily done with standard tools than with perl? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ FLAME BAIT ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Dan's version of "much more easily done" is different than for most of the rest of us, I think. -- -- uunet!sugar!karl -- Usenet access: (713) 438-5018
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/29/91)
In article <7628@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: > Dan's version of "much more easily done" is different than for most of > the rest of us, I think. Be serious, Karl. We're talking about seven simple commands in a pipeline versus nearly 30 lines of perl to do the same job: namely, get a list of all names where there are two different executables in PATH. It's a hell of a lot simpler to let ls, sort, and uniq do the work than to bother traversing directories, stat()ing files, and keeping arrays of on thing or another by hand. Surely you agree. Tom knows the shell script is a lot simpler; that's why he presented such brilliant arguments against it as ``It doesn't do anything like the perl script!'' and ``I'm giving you the silent treatment!'' ---Dan
maart@cs.vu.nl (Maarten Litmaath) (01/29/91)
In article <2856@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes: )[...] ) > test -f "$j/$i" && echo -n "$j/$i " As I noted before this will present /etc/passwd as `executable'. Adding a `test -x' will _not_ suffice, because `test' invokes access(2) to test executability, and the answers this system call gives _cannot_ be trusted if the real uid is 0 or if it differs from the effective uid. How does Perl implement `-x', Tom? -- kinnersley@kuhub.cc.ukans.edu (Bill Kinnersley): "Do phonograph turntables turn the other way in Australia?" gjh@krebs.acc.Virginia.EDU (Galen J. Hekhuis): "How do you think satanic messages were discovered on records?"
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (01/29/91)
In article <2856@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: > Dan moves on to another field giving a script > that gives all duplicate executables in your path; it does not look at the > arguments you give. Right. I started this subthread as a separate followup to Tom's first article. This has very little to do with the ``which'' thread (except that I don't think the function of ``which'' should be copied into a million separate scripts). The latter thread is also under a different subject line. > I have a few complaints Duly noted. > In article <1943:Jan2619:34:3591@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > for i in `ls -ilFL $dirs | > Complaint 1: ls complains about non existing directories that I have in my > path. Good point. Your change helps portability. > > rev | > Complaint 2: some of the (UNIX) systems I have access to tell me: > rev not found. Yes, so? When I try to run Tom's script, most of the UNIX systems I have access to tell me: perl not found. A few of the features he used didn't work the same in earlier versions of perl. All this means is that he requires your system to have a certain level of support. The same is true of my script. > What do I do now? Write a csh alias to do rev? You can work front-to-back on the lines if you want; sort and sed don't mind. To run this version, you have to, e.g., pick up the rev source and compile it---just as you need to compile perl if you don't have that. > > | sed -n -e 's/ .*//' -e 's/^\*//p' | > Complaint 3: Mmm. What with a filename that ends in an asterisk? Already noted, several times. > And > files with embedded blanks? There is no proper way to handle them, because of Tom's stilted output format. You might as well say that find is buggy because there's no way to separate filenames with null rather than newline. Sure, that leads to security holes; find still works. > > echo -n "$i: " > Complaint 4: On some (UNIX) systems this will not echo what you want. Same response as for rev; this is not a reasonable complaint. To port the program to those systems, you can use echo ... | tr -d '\012' if you want. > > echo '' > Why those quotes? Figure it out yourself. > Score: 8 lines of code, 3 correct. Be serious. The code does what it's meant to do in the situation I wrote it for. It is so short that it is trivial to port to any system. The same isn't true of Tom's maintenance mess. Sure, there are lots of limitations: if two different files on different devices have the same inode and appear with the same name in your path, then they won't be reported. Do I care? Sure, enough to mention this caveat in the documentation if I wrote a man page. That doesn't make the code incorrect. Exercise for the reader: Find three more portability problems and five more minor caveats. Yes, they exist. Will this stop people from using the script if they just want to find repeated executables in path? No. ---Dan
oz@yunexus.yorku.ca (Ozan Yigit) (02/01/91)
In article <18354:Jan2415:53:5391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Moral: Use the right tools for the right job. (And don't pretend that >adding a trivial script to an alt.sources.d posting makes it appropriate >for alt.sources.) Amen !!!! ... oz --- We only know ... what we know, and | Internet: oz@nexus.yorku.ca that is very little. -- Dan Rather | UUCP: utzoo/utai!yunexus!oz