maart@cs.vu.nl (09/02/88)
'sed -e' without any further argument dumps core. A fix should be easy.
casey@admin.cognet.ucla.edu (Casey Leedom) (09/03/88)
In article <1334@solo7.cs.vu.nl> maart@cs.vu.nl () writes: > 'sed -e' without any further argument dumps core. A fix should be easy. What version of 2BSD are you using? I just did this on our current 2.10BSD (soon to be released at the site near you) and didn't have any problems. Are you using 2.9BSD? Casey
dce@mips.COM (David Elliott) (09/03/88)
In article <15741@shemp.CS.UCLA.EDU> casey@admin.cognet.ucla.edu.UUCP (Casey Leedom) writes: >In article <1334@solo7.cs.vu.nl> maart@cs.vu.nl () writes: >> 'sed -e' without any further argument dumps core. A fix should be easy. > > What version of 2BSD are you using? I just did this on our current >2.10BSD (soon to be released at the site near you) and didn't have any >problems. Are you using 2.9BSD? If you're on a DEC machine, or any machine that allows dereferencing of NULL pointers, it probably works fine. This is one of those long-standing problems, and is present in both BSD and System V. There are actually 2 bugs. In the -f code, the check for enough arguments left checks to see if eargc is 1 and then decrements it, exiting if it isn't, but eargc can't be 1 at that point. The -e code doesn't even check for enough arguments in System V, but I seem to remember it does the same as for -f in BSD. Here's the fix for System V (the BSD code should be similar): *** sed0.c.old --- sed0.c *************** *** 97,106 **** continue; case 'f': ! if(eargc-- <= 0) exit(2); if((fin = fopen(*++eargv, "r")) == NULL) { ! fprintf(stderr, "Cannot open pattern-file: %s\n", *eargv); exit(2); } --- 97,110 ---- continue; case 'f': ! if (eargc < 2) { ! fprintf(stderr, "-f requires a file argument\n"); ! exit(2); ! } ! eargc--; if((fin = fopen(*++eargv, "r")) == NULL) { ! perror(*eargv); exit(2); } *************** *** 109,114 **** --- 113,122 ---- continue; case 'e': + if (eargc < 2) { + fprintf(stderr, "-e requires an argument\n"); + exit(2); + } eflag++; fcomp(); eflag = 0; -- David Elliott dce@mips.com or {ames,prls,pyramid,decwrl}!mips!dce
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (09/04/88)
In article <1334@solo7.cs.vu.nl>, maart@cs.vu.nl writes: > 'sed -e' without any further argument dumps core. > A fix should be easy. This is not useful information. Sed on what machine running what OS? If available, it would also be nice to know what version of sed (see what(1), or strings(1)) you were running. "sed -e" seems to work fine on 4.[0123]BSD and 4.3BSD-tahoe. Keith Bostic
ok@quintus.uucp (Richard A. O'Keefe) (09/05/88)
In article <25927@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes: >In article <1334@solo7.cs.vu.nl>, maart@cs.vu.nl writes: >> 'sed -e' without any further argument dumps core. >This is not useful information. Sed on what machine running what OS? This happens in SunOS 3.2 on a Sun-3/50 (sed[01].c 1.1 86/07/07), and SunOS 3.2rev2 on a Sun-4, but not in SunOS 4.0RRBeta2 on a 386i.
brian@radio.astro.toronto.edu (Brian Glendenning) (09/05/88)
It dumps core on our Sun running SunOS 3.5 for one.
--
Brian Glendenning INTERNET - brian@radio.astro.toronto.edu
Radio Astronomy, U. Toronto UUCP - {uunet,pyramid}!utai!radio!brian
+1 (416) 978-5558 BITNET - glendenn@utorphys.bitneteggert@sm.unisys.com (Paul Eggert) (09/06/88)
Richard A. O'Keefe writes that "sed -e" dumps core in older SunOS releases, but not on SunOS 4.0RRBeta2 on a 386i. This prompts me to dig out the following bug report for SunOS 4.0 on a Sun-3/60 (Sun bug ID 1012595): sed: "-e '' file" and "-f /dev/null file" treat the file name as a command When sed is given an empty script with the -e or -f flag, it gets confused and tries to grab the next argument as a command. The following script illustrates the problem. All three commands should do nothing, but only the first one works correctly. % sed '' /dev/null % sed -e '' /dev/null sed: Extra text at end of command: /dev/null % sed -f /dev/null /dev/null sed: Extra text at end of command: /dev/null This new bug does not exist under SunOS 3.5 on the same machine; 3.5 exhibited the old core dumping bug. So if you're fixing the "'sed -e' dumps core" bug, please check that you do not introduce this new bug, like Sun did.
maart@cs.vu.nl (Maarten Litmaath) (09/06/88)
In article <25927@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes: \In article <1334@solo7.cs.vu.nl>, maart@cs.vu.nl writes: \> 'sed -e' without any further argument dumps core. \> A fix should be easy. \ \This is not useful information. Sed on what machine running what \OS? If available, it would also be nice to know what version of \sed (see what(1), or strings(1)) you were running. "sed -e" seems \to work fine on 4.[0123]BSD and 4.3BSD-tahoe. \ \Keith Bostic On 2.9BSD on a PDP11/44 the output of 'sed -e | cat -v' is: Unrecognized command: M-pM-^@^]^B On Sun UNIX 4.2 Release 3.5 the output of 'what /bin/sed' is: /bin/sed crt0.s 1.2 86/10/07 Copyr 1985 Sun Micro sed0.c 1.2 86/10/07 SMI sed1.c 1.2 86/10/07 SMI fopen.c 1.2 86/10/07 SMI filbuf.c 1.2 86/10/07 SMI fprintf.c 1.2 86/10/07 SMI doprnt.c 1.4 87/07/01 SMI flsbuf.c 1.2 86/10/07 SMI exit.c 1.2 86/10/07 Copyr 1984 Sun Micro _itoa.s 1.2 86/10/07 Copyr 1984 Sun Micro ctype_.c 1.2 86/10/07 SMI findiop.c 1.2 86/10/07 SMI calloc.c 1.2 86/10/07 SMI malloc.c 1.3 86/10/07 SMI isinf.c 1.2 86/10/07 SMI memchr.c 1.2 86/10/07 SMI q.s 1.2 86/10/07 Copyr 1984 Sun Micro unpkd.s 1.2 86/10/07 Copyr 1984 Sun Micro upottab.c 1.2 86/10/07 Copyr 1984 Sun Micro isatty.c 1.2 86/10/07 SMI And the output of 'sed -e': Segmentation fault (core dumped) -- Alles klar, |Maarten Litmaath @ Free U Amsterdam: Herr Kommissar? |maart@cs.vu.nl, mcvax!botter!maart