home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / shell / 3113 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  1.9 KB
  1. Xref: sparky comp.unix.shell:3113 comp.unix.questions:9375
  2. Path: sparky!uunet!usc!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!friedman
  3. From: friedman@gnu.ai.mit.edu (Noah Friedman)
  4. Newsgroups: comp.unix.shell,comp.unix.questions
  5. Subject: Re: What's wrong with this sed command?
  6. Message-ID: <FRIEDMAN.92Jul24041305@nutrimat.gnu.ai.mit.edu>
  7. Date: 24 Jul 92 08:13:05 GMT
  8. References: <MONTNARO.92Jul21160321@ausable.crd.ge.com>
  9. Sender: news@ai.mit.edu
  10. Followup-To: comp.unix.shell
  11. Distribution: comp
  12. Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
  13. Lines: 27
  14. In-reply-to: montnaro@ausable.crd.ge.com's message of 21 Jul 92 21:03:21 GMT
  15.  
  16. In article <MONTNARO.92Jul21160321@ausable.crd.ge.com> montnaro@ausable.crd.ge.com (Skip Montanaro) writes:
  17. >I'm trying to use sed to trim off all leading "./" patterns from source
  18. >filenames in make rules. On an IBM RS6000 the following works as I expected:
  19. >
  20. >   echo 'enquire.o: ./././enquire.c' | sed 's?: \(\./\)\{1,\}?: ?'
  21. >
  22. >yielding
  23. >
  24. >   enquire.o: enquire.c
  25.  
  26.    It looks like you're trying to use some sort of extended regular
  27. expression here to match a consecutive range of regexps (in this case,
  28. starting with the first and going to the end).  I've never seen a version
  29. of sed that implements this (including GNU sed).  The following does what
  30. you wanted, however, and is quite portable:
  31.  
  32.    echo 'enquire.o: ./././enquire.c' | sed 's?: \(\./\)\1*?: ?'
  33.  
  34. The reason why this works should be obvious. 
  35.  
  36. >Have I incorrectly specified the sed command or are one (or more) of the
  37. >vendors' sed implementations incorrect? If so, which one(s)? I'm inclined to
  38. >believe the IBM is correct and the others are bugged.
  39.  
  40.    I don't know.  IBM may have made such an extension, but I'm not familiar
  41. with it.  But a trivial modification to your example makes it work across
  42. all the platforms you mentioned (I didn't bother quoting them in my reply).
  43.