sed(1) not branching to the end of the script

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

sed(1) not branching to the end of the script

Lars Noodén
I'm noticing some trouble with branching in sed(1) now.  Leaving the
label empty should branch to the end of the script:

      [2addr]b [label]
             Branch to the : function with the specified label.  If the label
             is not specified, branch to the end of the script.

However, in practice, when I try branching without a label, I get an
error about an undefined label instead of it branching to the end of
the script:

$ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
sed: 1: "/^START/,/^END/b;p;": undefined label ''

Adding a label works as expected:

$ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;

If I have not made a mistake with the short script above then there
seems to be a discrepancy between the behavior described in the manual
and the actual behavior.

dmesg below
/Lars

1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address
00:00:24:d1:fa:50
ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:51
ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:52
ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:53
ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
address 00:12:0e:61:54:68
ral0: MAC/BBP RT2561C, RF RT5225
pcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
version 1.0, legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
2.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
1.00/1.00 addr 1
softraid0 at root
scsibus0 at softraid0: 256 targets
sd0 at scsibus0 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd0: 2054MB, 512 bytes/sector, 4208128 sectors
sd1 at scsibus0 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd1: 5181MB, 512 bytes/sector, 10610944 sectors
root on rd0a swap on rd0b dump on rd0b
syncing disks... done
OpenBSD 6.4-current (GENERIC) #1024: Wed Nov 28 22:33:13 MST 2018
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 536363008 (511MB)
avail mem = 511528960 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/70/03, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 500 MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:00:24:cb:a9:24
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
address 00:00:24:cb:a9:25
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
address 00:00:24:cb:a9:26
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
address 00:00:24:cb:a9:27
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ppb0 at pci0 dev 14 function 0 "TI PCI2250" rev 0x02
pci1 at ppb0 bus 1
vr4 at pci1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:50
ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:51
ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:52
ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:53
ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
address 00:12:0e:61:54:68
ral0: MAC/BBP RT2561C, RF RT5225
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
version 1.0, legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
1.00/1.00 addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
sd0 at scsibus2 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd0: 2054MB, 512 bytes/sector, 4208128 sectors
sd1 at scsibus2 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd1: 5181MB, 512 bytes/sector, 10610944 sectors
root on wd0a (9ea76622cbdc8473.a) swap on wd0b dump on wd0b
vr5: restarting
syncing disks... done
OpenBSD 6.4-current (RAMDISK_CD) #1018: Mon Dec  3 22:07:19 MST 2018
    [hidden email]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
real mem  = 536408064 (511MB)
avail mem = 517574656 (493MB)
mainbus0 at root
bios0 at mainbus0: date 20/70/03, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 500 MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
"AMD Geode LX Crypto" rev 0x00 at pci0 dev 1 function 2 not configured
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:00:24:cb:a9:24
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
address 00:00:24:cb:a9:25
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
address 00:00:24:cb:a9:26
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
address 00:00:24:cb:a9:27
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ppb0 at pci0 dev 14 function 0 "TI PCI2250" rev 0x02
pci1 at ppb0 bus 1
vr4 at pci1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:50
ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:51
ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:52
ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:53
ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
address 00:12:0e:61:54:68
ral0: MAC/BBP RT2561C, RF RT5225
pcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
version 1.0, legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
2.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
1.00/1.00 addr 1
softraid0 at root
scsibus0 at softraid0: 256 targets
sd0 at scsibus0 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd0: 2054MB, 512 bytes/sector, 4208128 sectors
sd1 at scsibus0 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd1: 5181MB, 512 bytes/sector, 10610944 sectors
root on rd0a swap on rd0b dump on rd0b
syncing disks... done
OpenBSD 6.4-current (GENERIC) #1028: Mon Dec  3 21:49:53 MST 2018
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 536363008 (511MB)
avail mem = 511528960 (487MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/70/03, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
586-class) 500 MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
address 00:00:24:cb:a9:24
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
address 00:00:24:cb:a9:25
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
address 00:00:24:cb:a9:26
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
address 00:00:24:cb:a9:27
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ppb0 at pci0 dev 14 function 0 "TI PCI2250" rev 0x02
pci1 at ppb0 bus 1
vr4 at pci1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:50
ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:51
ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
address 00:00:24:d1:fa:52
ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
address 00:00:24:d1:fa:53
ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
0x004063, model 0x0034
ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
address 00:12:0e:61:54:68
ral0: MAC/BBP RT2561C, RF RT5225
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
32-bit 3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
version 1.0, legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
2.00/1.00 addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
1.00/1.00 addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
sd0 at scsibus2 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd0: 2054MB, 512 bytes/sector, 4208128 sectors
sd1 at scsibus2 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
sd1: 5181MB, 512 bytes/sector, 10610944 sectors
root on wd0a (9ea76622cbdc8473.a) swap on wd0b dump on wd0b

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Martijn van Duren-8
quick 7AM diff, may kill kittens.

martijn@

On 12/5/18 5:14 AM, Lars Noodén wrote:

> I'm noticing some trouble with branching in sed(1) now.  Leaving the
> label empty should branch to the end of the script:
>
>       [2addr]b [label]
>              Branch to the : function with the specified label.  If the label
>              is not specified, branch to the end of the script.
>
> However, in practice, when I try branching without a label, I get an
> error about an undefined label instead of it branching to the end of
> the script:
>
> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
> sed: 1: "/^START/,/^END/b;p;": undefined label ''
>
> Adding a label works as expected:
>
> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;
>
> If I have not made a mistake with the short script above then there
> seems to be a discrepancy between the behavior described in the manual
> and the actual behavior.
>
> dmesg below
> /Lars


Index: compile.c
===================================================================
RCS file: /cvs/src/usr.bin/sed/compile.c,v
retrieving revision 1.49
diff -u -p -r1.49 compile.c
--- compile.c 14 Aug 2018 18:10:09 -0000 1.49
+++ compile.c 5 Dec 2018 06:02:15 -0000
@@ -797,7 +797,8 @@ fixuplabel(struct s_command *cp, struct
  cp->u.c = NULL;
  break;
  }
- if ((cp->u.c = findlabel(cp->t)) == NULL)
+ if ((cp->u.c = findlabel(cp->t)) == NULL &&
+    *cp->t != '\0')
  error(COMPILE, "undefined label '%s'", cp->t);
  free(cp->t);
  break;

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Andreas Kusalananda Kähäri-4
In reply to this post by Lars Noodén
On Wed, Dec 05, 2018 at 06:14:34AM +0200, Lars Noodén wrote:

> I'm noticing some trouble with branching in sed(1) now.  Leaving the
> label empty should branch to the end of the script:
>
>       [2addr]b [label]
>              Branch to the : function with the specified label.  If the label
>              is not specified, branch to the end of the script.
>
> However, in practice, when I try branching without a label, I get an
> error about an undefined label instead of it branching to the end of
> the script:
>
> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
> sed: 1: "/^START/,/^END/b;p;": undefined label ''
>
> Adding a label works as expected:
>
> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;

No, adding the newlines makes it work.  The label has nothing to do with
it.

The label (empty or not) has to be delimited by a newline.  In your
first script, you could also have used

    sed -n -e '/^START/,/^END/b' -e p

(each -e inserts a newline in the script), or more simply

    sed '/^START/,/^END/d'

This is AFAIK standard behaviour.

From POSIX:

    Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
    followed by a <semicolon>, optional <blank> characters, and
    another command verb.


Andreas

>
> If I have not made a mistake with the short script above then there
> seems to be a discrepancy between the behavior described in the manual
> and the actual behavior.
>
> dmesg below
> /Lars
>
> 1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10, address
> 00:00:24:d1:fa:50
> ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:51
> ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:52
> ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:53
> ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
> address 00:12:0e:61:54:68
> ral0: MAC/BBP RT2561C, RF RT5225
> pcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
> wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
> wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
> wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
> version 1.0, legacy support
> ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
> 2.00/1.00 addr 1
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbc0: unable to establish interrupt for irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
> 1.00/1.00 addr 1
> softraid0 at root
> scsibus0 at softraid0: 256 targets
> sd0 at scsibus0 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd0: 2054MB, 512 bytes/sector, 4208128 sectors
> sd1 at scsibus0 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd1: 5181MB, 512 bytes/sector, 10610944 sectors
> root on rd0a swap on rd0b dump on rd0b
> syncing disks... done
> OpenBSD 6.4-current (GENERIC) #1024: Wed Nov 28 22:33:13 MST 2018
>     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 536363008 (511MB)
> avail mem = 511528960 (487MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/70/03, BIOS32 rev. 0 @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #1 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> 586-class) 500 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> 0:20:0: io address conflict 0x6100/0x100
> 0:20:0: io address conflict 0x6200/0x200
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:00:24:cb:a9:24
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
> address 00:00:24:cb:a9:25
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
> address 00:00:24:cb:a9:26
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
> address 00:00:24:cb:a9:27
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ppb0 at pci0 dev 14 function 0 "TI PCI2250" rev 0x02
> pci1 at ppb0 bus 1
> vr4 at pci1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:50
> ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:51
> ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:52
> ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:53
> ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
> address 00:12:0e:61:54:68
> ral0: MAC/BBP RT2561C, RF RT5225
> glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
> 32-bit 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
> wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
> wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
> wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
> version 1.0, legacy support
> ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
> 2.00/1.00 addr 1
> isa0 at glxpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbc0: unable to establish interrupt for irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
> gpio1 at nsclpcsio0: 29 pins
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
> 1.00/1.00 addr 1
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> sd0 at scsibus2 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd0: 2054MB, 512 bytes/sector, 4208128 sectors
> sd1 at scsibus2 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd1: 5181MB, 512 bytes/sector, 10610944 sectors
> root on wd0a (9ea76622cbdc8473.a) swap on wd0b dump on wd0b
> vr5: restarting
> syncing disks... done
> OpenBSD 6.4-current (RAMDISK_CD) #1018: Mon Dec  3 22:07:19 MST 2018
>     [hidden email]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
> real mem  = 536408064 (511MB)
> avail mem = 517574656 (493MB)
> mainbus0 at root
> bios0 at mainbus0: date 20/70/03, BIOS32 rev. 0 @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #1 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> 586-class) 500 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> 0:20:0: io address conflict 0x6100/0x100
> 0:20:0: io address conflict 0x6200/0x200
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> "AMD Geode LX Crypto" rev 0x00 at pci0 dev 1 function 2 not configured
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:00:24:cb:a9:24
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
> address 00:00:24:cb:a9:25
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
> address 00:00:24:cb:a9:26
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
> address 00:00:24:cb:a9:27
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ppb0 at pci0 dev 14 function 0 "TI PCI2250" rev 0x02
> pci1 at ppb0 bus 1
> vr4 at pci1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:50
> ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:51
> ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:52
> ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:53
> ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
> address 00:12:0e:61:54:68
> ral0: MAC/BBP RT2561C, RF RT5225
> pcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
> wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
> wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
> wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
> version 1.0, legacy support
> ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
> 2.00/1.00 addr 1
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbc0: unable to establish interrupt for irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
> 1.00/1.00 addr 1
> softraid0 at root
> scsibus0 at softraid0: 256 targets
> sd0 at scsibus0 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd0: 2054MB, 512 bytes/sector, 4208128 sectors
> sd1 at scsibus0 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd1: 5181MB, 512 bytes/sector, 10610944 sectors
> root on rd0a swap on rd0b dump on rd0b
> syncing disks... done
> OpenBSD 6.4-current (GENERIC) #1028: Mon Dec  3 21:49:53 MST 2018
>     [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 536363008 (511MB)
> avail mem = 511528960 (487MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 20/70/03, BIOS32 rev. 0 @ 0xfac40
> pcibios0 at bios0: rev 2.0 @ 0xf0000/0x10000
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #1 is the last bus
> bios0: ROM list: 0xc8000/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD"
> 586-class) 500 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
> mtrr: K6-family MTRR support (2 registers)
> amdmsr0 at mainbus0
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> 0:20:0: io address conflict 0x6100/0x100
> 0:20:0: io address conflict 0x6200/0x200
> pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
> glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
> vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11,
> address 00:00:24:cb:a9:24
> ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5,
> address 00:00:24:cb:a9:25
> ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9,
> address 00:00:24:cb:a9:26
> ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12,
> address 00:00:24:cb:a9:27
> ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ppb0 at pci0 dev 14 function 0 "TI PCI2250" rev 0x02
> pci1 at ppb0 bus 1
> vr4 at pci1 dev 0 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:50
> ukphy4 at vr4 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr5 at pci1 dev 1 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:51
> ukphy5 at vr5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr6 at pci1 dev 2 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 10,
> address 00:00:24:d1:fa:52
> ukphy6 at vr6 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> vr7 at pci1 dev 3 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 6,
> address 00:00:24:d1:fa:53
> ukphy7 at vr7 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x004063, model 0x0034
> ral0 at pci0 dev 17 function 0 "Ralink RT2561S" rev 0x00: irq 15,
> address 00:12:0e:61:54:68
> ral0: MAC/BBP RT2561C, RF RT5225
> glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3,
> 32-bit 3579545Hz timer, watchdog, gpio, i2c
> gpio0 at glxpcib0: 32 pins
> iic0 at glxpcib0
> pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> wd0 at pciide0 channel 0 drive 0: <SanDisk SDCFH-004G>
> wd0: 1-sector PIO, LBA48, 3825MB, 7835184 sectors
> wd1 at pciide0 channel 0 drive 1: <ELITE PRO CF CARD 4GB>
> wd1: 1-sector PIO, LBA, 3823MB, 7831152 sectors
> wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
> wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
> pciide0: channel 1 ignored (disabled)
> ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 7,
> version 1.0, legacy support
> ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 7
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev
> 2.00/1.00 addr 1
> isa0 at glxpcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbc0: unable to establish interrupt for irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
> gpio1 at nsclpcsio0: 29 pins
> npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev
> 1.00/1.00 addr 1
> vscsi0 at root
> scsibus1 at vscsi0: 256 targets
> softraid0 at root
> scsibus2 at softraid0: 256 targets
> sd0 at scsibus2 targ 1 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd0: 2054MB, 512 bytes/sector, 4208128 sectors
> sd1 at scsibus2 targ 2 lun 0: <OPENBSD, SR RAID 0, 006> SCSI2 0/direct fixed
> sd1: 5181MB, 512 bytes/sector, 10610944 sectors
> root on wd0a (9ea76622cbdc8473.a) swap on wd0b dump on wd0b

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Andreas Kusalananda Kähäri-4
On Wed, Dec 05, 2018 at 08:09:30AM +0100, Andreas Kusalananda Kähäri wrote:

> On Wed, Dec 05, 2018 at 06:14:34AM +0200, Lars Noodén wrote:
> > I'm noticing some trouble with branching in sed(1) now.  Leaving the
> > label empty should branch to the end of the script:
> >
> >       [2addr]b [label]
> >              Branch to the : function with the specified label.  If the label
> >              is not specified, branch to the end of the script.
> >
> > However, in practice, when I try branching without a label, I get an
> > error about an undefined label instead of it branching to the end of
> > the script:
> >
> > $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
> > sed: 1: "/^START/,/^END/b;p;": undefined label ''
> >
> > Adding a label works as expected:
> >
> > $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;
>
> No, adding the newlines makes it work.  The label has nothing to do with
> it.

Sorry, too early in the morning to be reading code and make a difference
between code and data, inserting a label seems to make it work (but
I'm unsure why; sure, it's convenient, but why do we have it?)  Still,
a portable sed script should have a newline after the "b" (and ":")
commands, not a semicolon.

>
> The label (empty or not) has to be delimited by a newline.  In your
> first script, you could also have used
>
>     sed -n -e '/^START/,/^END/b' -e p
>
> (each -e inserts a newline in the script), or more simply
>
>     sed '/^START/,/^END/d'
>
> This is AFAIK standard behaviour.
>
> >From POSIX:
>
>     Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
>     followed by a <semicolon>, optional <blank> characters, and
>     another command verb.
>
>
> Andreas
>
> >
> > If I have not made a mistake with the short script above then there
> > seems to be a discrepancy between the behavior described in the manual
> > and the actual behavior.
> >
> > dmesg below
> > /Lars
> >
[cut]

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Martijn van Duren-8
On 12/5/18 8:23 AM, Andreas Kusalananda Kähäri wrote:

> On Wed, Dec 05, 2018 at 08:09:30AM +0100, Andreas Kusalananda Kähäri wrote:
>> On Wed, Dec 05, 2018 at 06:14:34AM +0200, Lars Noodén wrote:
>>> I'm noticing some trouble with branching in sed(1) now.  Leaving the
>>> label empty should branch to the end of the script:
>>>
>>>       [2addr]b [label]
>>>              Branch to the : function with the specified label.  If the label
>>>              is not specified, branch to the end of the script.
>>>
>>> However, in practice, when I try branching without a label, I get an
>>> error about an undefined label instead of it branching to the end of
>>> the script:
>>>
>>> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
>>> sed: 1: "/^START/,/^END/b;p;": undefined label ''
>>>
>>> Adding a label works as expected:
>>>
>>> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;
>>
>> No, adding the newlines makes it work.  The label has nothing to do with
>> it.
>
> Sorry, too early in the morning to be reading code and make a difference
> between code and data, inserting a label seems to make it work (but
> I'm unsure why; sure, it's convenient, but why do we have it?)  Still,
> a portable sed script should have a newline after the "b" (and ":")
> commands, not a semicolon.

It seems you're right, although apparently gnu does support the
semicolon. Note that the label should consist of "portable filename
character set" characters, so adding the semicolon support doesn't break
compatibility too bad. Although it is a violation, not an extension on
unspecified behaviour (only unspecified behaviour is for is for
s/../../w).

So our options are:
1) Be extremely pedantic and check everything is within POSIX spec.
2) Remove support for semicolon and be more in line with POSIX. This
   way we get the semicolon as a label-character for free and removes
   the most LoC.
3) Keep violating POSIX, but make the behaviour consistent, similar to
   what gnu sed does.

Personally I would prefer option 1, since that would help write portable
scripts, but probably breaks a lot. Option 2 will probably also break a
few things, so I bet people will vote for option 3.

martijn@

>
>>
>> The label (empty or not) has to be delimited by a newline.  In your
>> first script, you could also have used
>>
>>     sed -n -e '/^START/,/^END/b' -e p
>>
>> (each -e inserts a newline in the script), or more simply
>>
>>     sed '/^START/,/^END/d'
>>
>> This is AFAIK standard behaviour.
>>
>> >From POSIX:
>>
>>     Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
>>     followed by a <semicolon>, optional <blank> characters, and
>>     another command verb.
>>
>>
>> Andreas
>>
>>>
>>> If I have not made a mistake with the short script above then there
>>> seems to be a discrepancy between the behavior described in the manual
>>> and the actual behavior.
>>>
>>> dmesg below
>>> /Lars
>>>
> [cut]
>
Option 1:
Index: compile.c
===================================================================
RCS file: /cvs/src/usr.bin/sed/compile.c,v
retrieving revision 1.49
diff -u -p -r1.49 compile.c
--- compile.c 14 Aug 2018 18:10:09 -0000 1.49
+++ compile.c 5 Dec 2018 08:10:35 -0000
@@ -73,6 +73,7 @@ static struct s_command
  *findlabel(char *);
 static void  fixuplabel(struct s_command *, struct s_command *);
 static void  uselabel(void);
+static void  validlabel(const char *);
 
 /*
  * Command specification.  This is used to drive the command parser.
@@ -287,23 +288,17 @@ nonsel: /* Now parse the command */
  if (*p == '\0')
  cmd->t = NULL;
  else
- cmd->t = duptoeol(p, "branch", &p);
- if (*p == ';') {
- p++;
- goto semicolon;
- }
+ cmd->t = duptoeol(p, "branch", NULL);
+ validlabel(cmd->t);
  break;
  case LABEL: /* : */
  p++;
  EATSPACE();
- cmd->t = duptoeol(p, "label", &p);
+ cmd->t = duptoeol(p, "label", NULL);
+ validlabel(cmd->t);
  if (strlen(cmd->t) == 0)
  error(COMPILE, "empty label");
  enterlabel(cmd);
- if (*p == ';') {
- p++;
- goto semicolon;
- }
  break;
  case SUBST: /* s */
  p++;
@@ -873,4 +868,18 @@ uselabel(void)
  free(lh);
  }
  }
+}
+
+static void
+validlabel(const char *name)
+{
+ size_t i, len;
+ if ((len = strlen(name)) > 8)
+ error(COMPILE, "label too long");
+ for (i = 0; i < len; i++) {
+ if (!isalnum(name[i]) && name[i] != '.' && name[i] != '_'
+    && name[i] != '-')
+ error(COMPILE, "Invalid label character");
+ }
+
 }

Option 2:
Index: compile.c
===================================================================
RCS file: /cvs/src/usr.bin/sed/compile.c,v
retrieving revision 1.49
diff -u -p -r1.49 compile.c
--- compile.c 14 Aug 2018 18:10:09 -0000 1.49
+++ compile.c 5 Dec 2018 07:56:59 -0000
@@ -287,23 +287,15 @@ nonsel: /* Now parse the command */
  if (*p == '\0')
  cmd->t = NULL;
  else
- cmd->t = duptoeol(p, "branch", &p);
- if (*p == ';') {
- p++;
- goto semicolon;
- }
+ cmd->t = duptoeol(p, "branch", NULL);
  break;
  case LABEL: /* : */
  p++;
  EATSPACE();
- cmd->t = duptoeol(p, "label", &p);
+ cmd->t = duptoeol(p, "label", NULL);
  if (strlen(cmd->t) == 0)
  error(COMPILE, "empty label");
  enterlabel(cmd);
- if (*p == ';') {
- p++;
- goto semicolon;
- }
  break;
  case SUBST: /* s */
  p++;
Option 3:
Index: compile.c
===================================================================
RCS file: /cvs/src/usr.bin/sed/compile.c,v
retrieving revision 1.49
diff -u -p -r1.49 compile.c
--- compile.c 14 Aug 2018 18:10:09 -0000 1.49
+++ compile.c 5 Dec 2018 08:00:11 -0000
@@ -286,8 +286,12 @@ nonsel: /* Now parse the command */
  EATSPACE();
  if (*p == '\0')
  cmd->t = NULL;
- else
+ else {
  cmd->t = duptoeol(p, "branch", &p);
+ if (strlen(cmd->t) == 0)
+ free(cmd->t);
+ cmd->t = NULL;
+ }
  if (*p == ';') {
  p++;
  goto semicolon;

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Andreas Kusalananda Kähäri-4
On Wed, Dec 05, 2018 at 09:24:05AM +0100, Martijn van Duren wrote:

> On 12/5/18 8:23 AM, Andreas Kusalananda Kähäri wrote:
> > On Wed, Dec 05, 2018 at 08:09:30AM +0100, Andreas Kusalananda Kähäri wrote:
> >> On Wed, Dec 05, 2018 at 06:14:34AM +0200, Lars Noodén wrote:
> >>> I'm noticing some trouble with branching in sed(1) now.  Leaving the
> >>> label empty should branch to the end of the script:
> >>>
> >>>       [2addr]b [label]
> >>>              Branch to the : function with the specified label.  If the label
> >>>              is not specified, branch to the end of the script.
> >>>
> >>> However, in practice, when I try branching without a label, I get an
> >>> error about an undefined label instead of it branching to the end of
> >>> the script:
> >>>
> >>> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
> >>> sed: 1: "/^START/,/^END/b;p;": undefined label ''
> >>>
> >>> Adding a label works as expected:
> >>>
> >>> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;
> >>
> >> No, adding the newlines makes it work.  The label has nothing to do with
> >> it.
> >
> > Sorry, too early in the morning to be reading code and make a difference
> > between code and data, inserting a label seems to make it work (but
> > I'm unsure why; sure, it's convenient, but why do we have it?)  Still,
> > a portable sed script should have a newline after the "b" (and ":")
> > commands, not a semicolon.
>
> It seems you're right, although apparently gnu does support the
> semicolon. Note that the label should consist of "portable filename
> character set" characters, so adding the semicolon support doesn't break
> compatibility too bad. Although it is a violation, not an extension on
> unspecified behaviour (only unspecified behaviour is for is for
> s/../../w).
>
> So our options are:
> 1) Be extremely pedantic and check everything is within POSIX spec.

This would get my vote as well.

> 2) Remove support for semicolon and be more in line with POSIX. This
>    way we get the semicolon as a label-character for free and removes
>    the most LoC.

Although the standard, as far as I can see right now, says nothing
about what characters are supposed to be valid in a label (only that an
implementation should support labels of length 8, at least), it feels
really weird to have semicolon as a label character...

> 3) Keep violating POSIX, but make the behaviour consistent, similar to
>    what gnu sed does.

I'm generally opposed to extra conveniences like these, especially if
they aren't actually needed for any other reason than to cater for
people who grew up on GNU systems.  However, a consistent behaviour
would definitely be good; either "b;" *and* "blabel;" (and ":label;")
works (the way GNU does it), or they generate some diagnostic (as with
Option 1).

The merit of the bug report is that it points out that the current
behaviour appears to be inconsistent.

Regards,
Andreas

>
> Personally I would prefer option 1, since that would help write portable
> scripts, but probably breaks a lot. Option 2 will probably also break a
> few things, so I bet people will vote for option 3.
>
> martijn@
> >
> >>
> >> The label (empty or not) has to be delimited by a newline.  In your
> >> first script, you could also have used
> >>
> >>     sed -n -e '/^START/,/^END/b' -e p
> >>
> >> (each -e inserts a newline in the script), or more simply
> >>
> >>     sed '/^START/,/^END/d'
> >>
> >> This is AFAIK standard behaviour.
> >>
> >> >From POSIX:
> >>
> >>     Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
> >>     followed by a <semicolon>, optional <blank> characters, and
> >>     another command verb.
> >>
> >>
> >> Andreas
> >>
> >>>
> >>> If I have not made a mistake with the short script above then there
> >>> seems to be a discrepancy between the behavior described in the manual
> >>> and the actual behavior.
> >>>
> >>> dmesg below
> >>> /Lars
> >>>
> > [cut]
> >
> Option 1:
> Index: compile.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/sed/compile.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 compile.c
> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
> +++ compile.c 5 Dec 2018 08:10:35 -0000
> @@ -73,6 +73,7 @@ static struct s_command
>   *findlabel(char *);
>  static void  fixuplabel(struct s_command *, struct s_command *);
>  static void  uselabel(void);
> +static void  validlabel(const char *);
>  
>  /*
>   * Command specification.  This is used to drive the command parser.
> @@ -287,23 +288,17 @@ nonsel: /* Now parse the command */
>   if (*p == '\0')
>   cmd->t = NULL;
>   else
> - cmd->t = duptoeol(p, "branch", &p);
> - if (*p == ';') {
> - p++;
> - goto semicolon;
> - }
> + cmd->t = duptoeol(p, "branch", NULL);
> + validlabel(cmd->t);
>   break;
>   case LABEL: /* : */
>   p++;
>   EATSPACE();
> - cmd->t = duptoeol(p, "label", &p);
> + cmd->t = duptoeol(p, "label", NULL);
> + validlabel(cmd->t);
>   if (strlen(cmd->t) == 0)
>   error(COMPILE, "empty label");
>   enterlabel(cmd);
> - if (*p == ';') {
> - p++;
> - goto semicolon;
> - }
>   break;
>   case SUBST: /* s */
>   p++;
> @@ -873,4 +868,18 @@ uselabel(void)
>   free(lh);
>   }
>   }
> +}
> +
> +static void
> +validlabel(const char *name)
> +{
> + size_t i, len;
> + if ((len = strlen(name)) > 8)
> + error(COMPILE, "label too long");
> + for (i = 0; i < len; i++) {
> + if (!isalnum(name[i]) && name[i] != '.' && name[i] != '_'
> +    && name[i] != '-')
> + error(COMPILE, "Invalid label character");
> + }
> +
>  }
>
> Option 2:
> Index: compile.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/sed/compile.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 compile.c
> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
> +++ compile.c 5 Dec 2018 07:56:59 -0000
> @@ -287,23 +287,15 @@ nonsel: /* Now parse the command */
>   if (*p == '\0')
>   cmd->t = NULL;
>   else
> - cmd->t = duptoeol(p, "branch", &p);
> - if (*p == ';') {
> - p++;
> - goto semicolon;
> - }
> + cmd->t = duptoeol(p, "branch", NULL);
>   break;
>   case LABEL: /* : */
>   p++;
>   EATSPACE();
> - cmd->t = duptoeol(p, "label", &p);
> + cmd->t = duptoeol(p, "label", NULL);
>   if (strlen(cmd->t) == 0)
>   error(COMPILE, "empty label");
>   enterlabel(cmd);
> - if (*p == ';') {
> - p++;
> - goto semicolon;
> - }
>   break;
>   case SUBST: /* s */
>   p++;
> Option 3:
> Index: compile.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/sed/compile.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 compile.c
> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
> +++ compile.c 5 Dec 2018 08:00:11 -0000
> @@ -286,8 +286,12 @@ nonsel: /* Now parse the command */
>   EATSPACE();
>   if (*p == '\0')
>   cmd->t = NULL;
> - else
> + else {
>   cmd->t = duptoeol(p, "branch", &p);
> + if (strlen(cmd->t) == 0)
> + free(cmd->t);
> + cmd->t = NULL;
> + }
>   if (*p == ';') {
>   p++;
>   goto semicolon;

--
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Martijn van Duren-8
On 12/5/18 11:56 AM, Andreas Kusalananda Kähäri wrote:

> On Wed, Dec 05, 2018 at 09:24:05AM +0100, Martijn van Duren wrote:
>> On 12/5/18 8:23 AM, Andreas Kusalananda Kähäri wrote:
>>> On Wed, Dec 05, 2018 at 08:09:30AM +0100, Andreas Kusalananda Kähäri wrote:
>>>> On Wed, Dec 05, 2018 at 06:14:34AM +0200, Lars Noodén wrote:
>>>>> I'm noticing some trouble with branching in sed(1) now.  Leaving the
>>>>> label empty should branch to the end of the script:
>>>>>
>>>>>       [2addr]b [label]
>>>>>              Branch to the : function with the specified label.  If the label
>>>>>              is not specified, branch to the end of the script.
>>>>>
>>>>> However, in practice, when I try branching without a label, I get an
>>>>> error about an undefined label instead of it branching to the end of
>>>>> the script:
>>>>>
>>>>> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/b;p;'
>>>>> sed: 1: "/^START/,/^END/b;p;": undefined label ''
>>>>>
>>>>> Adding a label works as expected:
>>>>>
>>>>> $ echo -e "START\nfoo\nbar\nEND\nbaz\n" | sed -n '/^START/,/^END/ba;p;:a;
>>>>
>>>> No, adding the newlines makes it work.  The label has nothing to do with
>>>> it.
>>>
>>> Sorry, too early in the morning to be reading code and make a difference
>>> between code and data, inserting a label seems to make it work (but
>>> I'm unsure why; sure, it's convenient, but why do we have it?)  Still,
>>> a portable sed script should have a newline after the "b" (and ":")
>>> commands, not a semicolon.
>>
>> It seems you're right, although apparently gnu does support the
>> semicolon. Note that the label should consist of "portable filename
>> character set" characters, so adding the semicolon support doesn't break
>> compatibility too bad. Although it is a violation, not an extension on
>> unspecified behaviour (only unspecified behaviour is for is for
>> s/../../w).
>>
>> So our options are:
>> 1) Be extremely pedantic and check everything is within POSIX spec.
>
> This would get my vote as well.

Just to be clear; this wouldn't get my vote per se, I would just prefer
this. The risk of breaking too many things is too real, so it's not a
safe option.

I added it here mostly for illustration purposes.
>
>> 2) Remove support for semicolon and be more in line with POSIX. This
>>    way we get the semicolon as a label-character for free and removes
>>    the most LoC.
>
> Although the standard, as far as I can see right now, says nothing
> about what characters are supposed to be valid in a label (only that an
> implementation should support labels of length 8, at least), it feels
> really weird to have semicolon as a label character...

POSIX states[0]:
If a label argument (to a b, t, or : command) contains characters
outside of the portable filename character set, or if a label is longer
than 8 bytes, the behavior is unspecified.

So supported characters are[1]:
alnum, dot, underscore, hyphen

So the semicolon is not disallowed, because it's behaviour unspecified.

>
>> 3) Keep violating POSIX, but make the behaviour consistent, similar to
>>    what gnu sed does.
>
> I'm generally opposed to extra conveniences like these, especially if
> they aren't actually needed for any other reason than to cater for
> people who grew up on GNU systems.  However, a consistent behaviour
> would definitely be good; either "b;" *and* "blabel;" (and ":label;")
> works (the way GNU does it), or they generate some diagnostic (as with
> Option 1).

The problem is, there's also ports to consider, who sometimes use base
sed in their build infrastructure; Changing sed to option 1 could
potentially break quite a few packages, which then would have to be
fixed by the ports maintainers and hope that upstream accepts the
patches. So sometimes you have to follow the idiosyncrasies of the bigger
party.
>
> The merit of the bug report is that it points out that the current
> behaviour appears to be inconsistent.

I agree.

>
> Regards,
> Andreas
>
>>
>> Personally I would prefer option 1, since that would help write portable
>> scripts, but probably breaks a lot. Option 2 will probably also break a
>> few things, so I bet people will vote for option 3.
>>
>> martijn@
>>>
>>>>
>>>> The label (empty or not) has to be delimited by a newline.  In your
>>>> first script, you could also have used
>>>>
>>>>     sed -n -e '/^START/,/^END/b' -e p
>>>>
>>>> (each -e inserts a newline in the script), or more simply
>>>>
>>>>     sed '/^START/,/^END/d'
>>>>
>>>> This is AFAIK standard behaviour.
>>>>
>>>> >From POSIX:
>>>>
>>>>     Command verbs other than {, a, b, c, i, r, t, w, :, and # can be
>>>>     followed by a <semicolon>, optional <blank> characters, and
>>>>     another command verb.
>>>>
>>>>
>>>> Andreas
>>>>
>>>>>
>>>>> If I have not made a mistake with the short script above then there
>>>>> seems to be a discrepancy between the behavior described in the manual
>>>>> and the actual behavior.
>>>>>
>>>>> dmesg below
>>>>> /Lars
>>>>>
>>> [cut]
>>>
[0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Ingo Schwarze
In reply to this post by Martijn van Duren-8
Hi,

putting the minimal useful example in the place of longer quotations:

   $ printf "A\nB\n" | gsed '1b;='
  A
  2
  B
   $ printf "A\nB\n" | sed '1b;='  
  sed: 1: "1b;=": undefined label ''

Martijn van Duren wrote on Wed, Dec 05, 2018 at 09:24:05AM +0100:

> Note that the label should consist of "portable filename
> character set" characters, so adding the semicolon support doesn't break
> compatibility too bad. Although it is a violation, not an extension on
> unspecified behaviour (only unspecified behaviour is for is for
> s/../../w).

Why do you think it is a violation?

POSIX requires that "editing commands other than {...}, a, b, c, i, r, t,
w, :, and # can be followed by a <semicolon>...", but i don't see
anything that specifies what should happen if b is followed by a
semicolon.  So that case seems unspecified.  Our manual page is
somewhat fuzzy with respect to semicolons, but let's fix that after
deciding the behaviour.

Let's look at the likely reasons *why* POSIX does not require
semicolons to work after these commands:

 * a, c, i:
   These take text arguments, which can usefully contain semicolons.

 * #:
   Comments can usefully contain semicolons, too.

 * r, w:
   These take filename arguments, which might contain semicolons;
   it doesn't matter in this context that filenames containing
   semicolons are asking for trouble in other respects.

 * {...}:
   I see no reason for not allowing semicolons here, and indeed:

      $ printf "A\nB\n" | sed -n '{=;};p'
     1
     A
     2
     B

   Same for GNU sed.

That leaves us with b, t, : - which take label arguments.
Support for labels containing semicolons is explicitly
not required and would hardly be useful.

We already support semicolon-continuation after b, t, :,
and so does GNU sed:

   $ printf "A\nB\n" | sed -n '1bL;=;:L;p'
  A
  2
  B

   $ printf "A\nB\n" | sed -n 's/A/C/;tL;=;:L;p'
  C
  2
  B

Removing the existing support for semicolons after b, t, :
does not seem to me to make anything better, but might break
existing scripts or stuff in ports.

So it would seem best to me to only fix the case of b and t without
argument followed by a semicolon, to match GNU, which does the
logical and consistent thing here.

   $ printf "A\nB\n" | gsed '1b;='                
  A
  2
  B
   $ printf "A\nB\n" | gsed 's/A/C/;t;='  
  C
  2
  B

I didn't study your patch yet - is that what it does?

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Martijn van Duren-8
On 12/5/18 7:24 PM, Ingo Schwarze wrote:

> Hi,
>
> putting the minimal useful example in the place of longer quotations:
>
>    $ printf "A\nB\n" | gsed '1b;='
>   A
>   2
>   B
>    $ printf "A\nB\n" | sed '1b;='  
>   sed: 1: "1b;=": undefined label ''
>
> Martijn van Duren wrote on Wed, Dec 05, 2018 at 09:24:05AM +0100:
>
>> Note that the label should consist of "portable filename
>> character set" characters, so adding the semicolon support doesn't break
>> compatibility too bad. Although it is a violation, not an extension on
>> unspecified behaviour (only unspecified behaviour is for is for
>> s/../../w).
>
> Why do you think it is a violation?

Because POSIX goes out of its way to make it not obvious:
Editing commands other than {...}, a, b, c, i, r, t, w, :, and # can be
followed by a <semicolon>, optional <blank> characters, and another
editing command. However, when an s editing command is used with the w  
flag, following it with another command in this manner produces
undefined results.

They begin by a negation which can use a semicolon and then they follow
by explicitly stating where undefined behaviour lies. So assuming that
not including in "can" equals "may still", and assuming that the
undefined results section is a non-exhaustive list, or an exclusive for
the inverse group mentioned at the star, may result in undefined
behaviour. But combine the obscure language with the fact that there's a
profound reason to not use a semicolon in 6 out of the 10 exclude group
makes me wonder if it's not a violation why they went out of their way
to place them in the same list as a, c, i, r, w, #.

>
> POSIX requires that "editing commands other than {...}, a, b, c, i, r, t,
> w, :, and # can be followed by a <semicolon>...", but i don't see
> anything that specifies what should happen if b is followed by a
> semicolon.  So that case seems unspecified.  Our manual page is
> somewhat fuzzy with respect to semicolons, but let's fix that after
> deciding the behaviour.
>
> Let's look at the likely reasons *why* POSIX does not require
> semicolons to work after these commands:
>
>  * a, c, i:
>    These take text arguments, which can usefully contain semicolons.
>
>  * #:
>    Comments can usefully contain semicolons, too.
>
>  * r, w:
>    These take filename arguments, which might contain semicolons;
>    it doesn't matter in this context that filenames containing
>    semicolons are asking for trouble in other respects.
>
>  * {...}:
>    I see no reason for not allowing semicolons here, and indeed:
>
>       $ printf "A\nB\n" | sed -n '{=;};p'
>      1
>      A
>      2
>      B
>
>    Same for GNU sed.
>
> That leaves us with b, t, : - which take label arguments.
> Support for labels containing semicolons is explicitly
> not required and would hardly be useful.
>
> We already support semicolon-continuation after b, t, :,
> and so does GNU sed:
>
>    $ printf "A\nB\n" | sed -n '1bL;=;:L;p'
>   A
>   2
>   B
>
>    $ printf "A\nB\n" | sed -n 's/A/C/;tL;=;:L;p'
>   C
>   2
>   B
>
> Removing the existing support for semicolons after b, t, :
> does not seem to me to make anything better, but might break
> existing scripts or stuff in ports.
>
> So it would seem best to me to only fix the case of b and t without
> argument followed by a semicolon, to match GNU, which does the
> logical and consistent thing here.
>
>    $ printf "A\nB\n" | gsed '1b;='                
>   A
>   2
>   B
>    $ printf "A\nB\n" | gsed 's/A/C/;t;='  
>   C
>   2
>   B

I agree with your reasoning and I don't mind making it consistent, see
my previous mail about using option 3; but if you ask me if this in
line with what POSIX states, I'd argue it's not and if it is it's only
by the skin of its teeth.
>
> I didn't study your patch yet - is that what it does?

That's what patch option 3 does:
$ printf "A\nB\n" | ./sed '1b;='
A
2
B
>
> Yours,
>   Ingo
>

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Ingo Schwarze
In reply to this post by Martijn van Duren-8
Hi Martijn,

i think your patch does achieve the desired effect, but i'd prefer
the following one instead.  There is really no need to malloc(3) an
empty string, only to later translate and free it.

My version does not seems very dangerous.  All it changes is that,
if "b" or "t" is followed by optional whitespace, and then immediately
by a semicolon, branching is set up to the end of the script -
in exactly the same way as for "b" at the end of an input line -
instead of to a label with an empty name, which never exists.
Nothing else changes, in particular not parsing of subsequent input.

The test suite still succeeds.  Additional tests:

   $ echo "A\nB" | sed '1b;='  
  A
  2
  B

   $ echo "A\nB" | sed 's/A/C/;t;='          
  C
  2
  B

   $ echo "A\nB" | sed '1bL;=;:L'
  A
  2
  B

   $ echo "1b\n=" > tmp.sed; echo "A\nB" | sed -f tmp.sed
  A
  2
  B

Yours,
  Ingo


Index: compile.c
===================================================================
RCS file: /cvs/src/usr.bin/sed/compile.c,v
retrieving revision 1.49
diff -u -r1.49 compile.c
--- compile.c 14 Aug 2018 18:10:09 -0000 1.49
+++ compile.c 6 Dec 2018 19:07:31 -0000
@@ -284,7 +284,7 @@
  case BRANCH: /* b t */
  p++;
  EATSPACE();
- if (*p == '\0')
+ if (*p == '\0' || *p == ';')
  cmd->t = NULL;
  else
  cmd->t = duptoeol(p, "branch", &p);


> Index: compile.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/sed/compile.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 compile.c
> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
> +++ compile.c 5 Dec 2018 06:02:15 -0000
> @@ -797,7 +797,8 @@ fixuplabel(struct s_command *cp, struct
>   cp->u.c = NULL;
>   break;
>   }
> - if ((cp->u.c = findlabel(cp->t)) == NULL)
> + if ((cp->u.c = findlabel(cp->t)) == NULL &&
> +    *cp->t != '\0')
>   error(COMPILE, "undefined label '%s'", cp->t);
>   free(cp->t);
>   break;
>

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Martijn van Duren-8
You're right. Yours is a lot cleaner.
OK martijn@

On 12/6/18 8:31 PM, Ingo Schwarze wrote:

> Hi Martijn,
>
> i think your patch does achieve the desired effect, but i'd prefer
> the following one instead.  There is really no need to malloc(3) an
> empty string, only to later translate and free it.
>
> My version does not seems very dangerous.  All it changes is that,
> if "b" or "t" is followed by optional whitespace, and then immediately
> by a semicolon, branching is set up to the end of the script -
> in exactly the same way as for "b" at the end of an input line -
> instead of to a label with an empty name, which never exists.
> Nothing else changes, in particular not parsing of subsequent input.
>
> The test suite still succeeds.  Additional tests:
>
>    $ echo "A\nB" | sed '1b;='  
>   A
>   2
>   B
>
>    $ echo "A\nB" | sed 's/A/C/;t;='          
>   C
>   2
>   B
>
>    $ echo "A\nB" | sed '1bL;=;:L'
>   A
>   2
>   B
>
>    $ echo "1b\n=" > tmp.sed; echo "A\nB" | sed -f tmp.sed
>   A
>   2
>   B
>
> Yours,
>   Ingo
>
>
> Index: compile.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/sed/compile.c,v
> retrieving revision 1.49
> diff -u -r1.49 compile.c
> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
> +++ compile.c 6 Dec 2018 19:07:31 -0000
> @@ -284,7 +284,7 @@
>   case BRANCH: /* b t */
>   p++;
>   EATSPACE();
> - if (*p == '\0')
> + if (*p == '\0' || *p == ';')
>   cmd->t = NULL;
>   else
>   cmd->t = duptoeol(p, "branch", &p);
>
>
>> Index: compile.c
>> ===================================================================
>> RCS file: /cvs/src/usr.bin/sed/compile.c,v
>> retrieving revision 1.49
>> diff -u -p -r1.49 compile.c
>> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
>> +++ compile.c 5 Dec 2018 06:02:15 -0000
>> @@ -797,7 +797,8 @@ fixuplabel(struct s_command *cp, struct
>>   cp->u.c = NULL;
>>   break;
>>   }
>> - if ((cp->u.c = findlabel(cp->t)) == NULL)
>> + if ((cp->u.c = findlabel(cp->t)) == NULL &&
>> +    *cp->t != '\0')
>>   error(COMPILE, "undefined label '%s'", cp->t);
>>   free(cp->t);
>>   break;
>>

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Todd C. Miller-2
In reply to this post by Ingo Schwarze
On Thu, 06 Dec 2018 20:31:19 +0100, Ingo Schwarze wrote:

> My version does not seems very dangerous.  All it changes is that,
> if "b" or "t" is followed by optional whitespace, and then immediately
> by a semicolon, branching is set up to the end of the script -
> in exactly the same way as for "b" at the end of an input line -
> instead of to a label with an empty name, which never exists.
> Nothing else changes, in particular not parsing of subsequent input.

OK millert@ for your diff (and for a regress diff to add those new
tests).

 - todd

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Ingo Schwarze
In reply to this post by Martijn van Duren-8
Hi Martijn,

Martijn van Duren wrote on Thu, Dec 06, 2018 at 09:12:19PM +0100:

> OK martijn@

Thanks for checking!

After testing that "make build" and "make release" still works,
i just committed the patch.

Yours,
  Ingo



CVSROOT: /cvs
Module name: src
Changes by: [hidden email] 2018/12/07 07:45:40

Modified files:
        usr.bin/sed    : compile.c

Log message:
As an extension to POSIX, for consistency with our behaviour for
the "b" and "t" commands with a label, and for compatibility with
GNU sed, also accept ";" followed by another command after "b"
and "t" commands without a label: branch to the end of the script
instead of erroring out.  Parsing is unchanged.

Missing feature reported by Lars dot Nooden at gmail dot com on bugs@.
OK martijn@ millert@


>> Index: compile.c
>> ===================================================================
>> RCS file: /cvs/src/usr.bin/sed/compile.c,v
>> retrieving revision 1.49
>> diff -u -r1.49 compile.c
>> --- compile.c 14 Aug 2018 18:10:09 -0000 1.49
>> +++ compile.c 6 Dec 2018 19:07:31 -0000
>> @@ -284,7 +284,7 @@
>>   case BRANCH: /* b t */
>>   p++;
>>   EATSPACE();
>> - if (*p == '\0')
>> + if (*p == '\0' || *p == ';')
>>   cmd->t = NULL;
>>   else
>>   cmd->t = duptoeol(p, "branch", &p);
>>

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Ingo Schwarze
In reply to this post by Todd C. Miller-2
Hi Todd,

Todd C. Miller wrote on Thu, Dec 06, 2018 at 01:59:03PM -0700:
> On Thu, 06 Dec 2018 20:31:19 +0100, Ingo Schwarze wrote:

>> My version does not seems very dangerous.  All it changes is that,
>> if "b" or "t" is followed by optional whitespace, and then immediately
>> by a semicolon, branching is set up to the end of the script -
>> in exactly the same way as for "b" at the end of an input line -
>> instead of to a label with an empty name, which never exists.
>> Nothing else changes, in particular not parsing of subsequent input.

> OK millert@ for your diff

Thanks for checking.

> (and for a regress diff to add those new tests).

Done, too.

I'm not convinced it ever happened to me before this
that i received an OK for a patch which i hadn't even planned to write
before i received the OK...  :)

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Ingo Schwarze
In reply to this post by Martijn van Duren-8
Hi Martijn,

Martijn van Duren wrote on Thu, Dec 06, 2018 at 07:07:14AM +0100:
> On 12/5/18 7:24 PM, Ingo Schwarze wrote:

>> putting the minimal useful example in the place of longer quotations:
>>
>>    $ printf "A\nB\n" | gsed '1b;='
>>   A
>>   2
>>   B
>>    $ printf "A\nB\n" | sed '1b;='  
>>   sed: 1: "1b;=": undefined label ''

>> Martijn van Duren wrote on Wed, Dec 05, 2018 at 09:24:05AM +0100:

>>> Note that the label should consist of "portable filename
>>> character set" characters, so adding the semicolon support doesn't break
>>> compatibility too bad. Although it is a violation, not an extension on
>>> unspecified behaviour (only unspecified behaviour is for is for
>>> s/../../w).

>> Why do you think it is a violation?

> Because POSIX goes out of its way to make it not obvious:
> Editing commands other than {...}, a, b, c, i, r, t, w, :, and # can be
> followed by a <semicolon>, optional <blank> characters, and another
> editing command. However, when an s editing command is used with the w  
> flag, following it with another command in this manner produces
> undefined results.
>
> They begin by a negation which can use a semicolon and then they follow
> by explicitly stating where undefined behaviour lies. So assuming that
> not including in "can" equals "may still", and assuming that the
> undefined results section is a non-exhaustive list, or an exclusive for
> the inverse group mentioned at the star, may result in undefined
> behaviour. But combine the obscure language with the fact that there's a
> profound reason to not use a semicolon in 6 out of the 10 exclude group
> makes me wonder if it's not a violation why they went out of their way
> to place them in the same list as a, c, i, r, w, #.

Ah.  I think when reading a standard, one must carefully look what it
actually says, not jump to conclusions from how that is said.  Even when
logically unambiguous, the wording may sometimes sound confusing.
And sometimes, what is prescribed is unambiguous, but something else
would seem to make more sense.

No doubt it says what a semicolon is supposed to do after the
commands not listed.  No doubt it says that "s///w filename;something"
results in undefined behaviour - by the way, "undefined" is stronger
than "unspecified".  But i don't see that it says anywhere
what "b label;something" is supposed to do - so that is left
unspecified, and operating systems are free to implement and
document an extension.

By the way, we do have a case here of the specification looking
slightly ill-designed: "s///w filename;something" is explicitly
marked as undefined, whereas the even simpler "w filename;something"
is merely left unspecified.  But fortunately, we are not planning
to change the behaviour of "[s///]w filename;something", so we don't
need to worry about that right now.


All that said, i see a few problems with the manual page, so here is
a patch to fix it.

The information in the CAVEATS section is misplaced.  The purpose
of that section is to warn about typical programming mistakes, not
to explain what our implementation does nor to explain what the
standard requires.  Besides, it is wrong, semicolons *can* be used
after "b" and "t" with our implementation.  Finally, the current
wording can mislead people to think this might be forbidden:

  $ echo "A\nB" | sed '=;r suffix.txt'


So move the information about "a", "c", "i", "r", and "w" to the
DESCRIPTION.  I don't think it belongs into the second paragraph
from the top; even though that is where ";" is introduced, that
place would be way too prominent.  Below "SED FUNCTIONS", where
other special properties of groups of functions are also explained,
seems about right.

Move the information about "b", "t", and ":" to STANDARDS where it
belongs.  That commands in general can be separated with ";" was
already said at the very top of the page.

I don't think anything more needs to be said about "#".
We already have:

    The '#' and the remainder of the line are ignored (treated as a
    comment), with the single exception that if the first two
    characters in the file are '#n', the default output is
    [...]

It's kind of obvious the remainder of the line may contain ';'
and it will be ignored.

While here, avoid "permitted" - were aren't planning to send anybody
to jail for sed(1) abuse.

OK?
  Ingo


Index: sed.1
===================================================================
RCS file: /cvs/src/usr.bin/sed/sed.1,v
retrieving revision 1.57
diff -u -r1.57 sed.1
--- sed.1 14 Nov 2018 10:59:33 -0000 1.57
+++ sed.1 7 Dec 2018 16:48:14 -0000
@@ -277,6 +277,20 @@
 The synopses below indicate which arguments have to be separated from
 the function letters by whitespace characters.
 .Pp
+The
+.Ic a ,
+.Ic c ,
+.Ic i ,
+.Ic r ,
+and
+.Ic w
+functions cannot be followed by another command separated with a semicolon.
+The
+.Ar text
+and
+.Ar file
+arguments may contain semicolon characters.
+.Pp
 Functions can be combined to form a
 .Em function list ,
 a list of
@@ -561,6 +575,14 @@
 .Op Fl aEiru
 are extensions to that specification.
 .Pp
+Following the
+.Ic b ,
+.Ic t ,
+or
+.Ic \&:
+commands with a semicolon and another command is an extension to the
+specification.
+.Pp
 The use of newlines to separate multiple commands on the command line
 is non-portable;
 the use of newlines to separate multiple commands within a command file
@@ -571,11 +593,3 @@
 .Nm
 command appeared in
 .At v7 .
-.Sh CAVEATS
-The use of semicolons to separate multiple commands
-is not permitted for the following commands:
-.Ic a , b , c ,
-.Ic i , r , t ,
-.Ic w , \&: ,
-and
-.Ic # .

Reply | Threaded
Open this post in threaded view
|

Re: sed(1) not branching to the end of the script

Jason McIntyre-2
On Fri, Dec 07, 2018 at 06:23:35PM +0100, Ingo Schwarze wrote:

> Hi Martijn,
>
> Martijn van Duren wrote on Thu, Dec 06, 2018 at 07:07:14AM +0100:
> > On 12/5/18 7:24 PM, Ingo Schwarze wrote:
>
> >> putting the minimal useful example in the place of longer quotations:
> >>
> >>    $ printf "A\nB\n" | gsed '1b;='
> >>   A
> >>   2
> >>   B
> >>    $ printf "A\nB\n" | sed '1b;='  
> >>   sed: 1: "1b;=": undefined label ''
>
> >> Martijn van Duren wrote on Wed, Dec 05, 2018 at 09:24:05AM +0100:
>
> >>> Note that the label should consist of "portable filename
> >>> character set" characters, so adding the semicolon support doesn't break
> >>> compatibility too bad. Although it is a violation, not an extension on
> >>> unspecified behaviour (only unspecified behaviour is for is for
> >>> s/../../w).
>
> >> Why do you think it is a violation?
>
> > Because POSIX goes out of its way to make it not obvious:
> > Editing commands other than {...}, a, b, c, i, r, t, w, :, and # can be
> > followed by a <semicolon>, optional <blank> characters, and another
> > editing command. However, when an s editing command is used with the w  
> > flag, following it with another command in this manner produces
> > undefined results.
> >
> > They begin by a negation which can use a semicolon and then they follow
> > by explicitly stating where undefined behaviour lies. So assuming that
> > not including in "can" equals "may still", and assuming that the
> > undefined results section is a non-exhaustive list, or an exclusive for
> > the inverse group mentioned at the star, may result in undefined
> > behaviour. But combine the obscure language with the fact that there's a
> > profound reason to not use a semicolon in 6 out of the 10 exclude group
> > makes me wonder if it's not a violation why they went out of their way
> > to place them in the same list as a, c, i, r, w, #.
>
> Ah.  I think when reading a standard, one must carefully look what it
> actually says, not jump to conclusions from how that is said.  Even when
> logically unambiguous, the wording may sometimes sound confusing.
> And sometimes, what is prescribed is unambiguous, but something else
> would seem to make more sense.
>
> No doubt it says what a semicolon is supposed to do after the
> commands not listed.  No doubt it says that "s///w filename;something"
> results in undefined behaviour - by the way, "undefined" is stronger
> than "unspecified".  But i don't see that it says anywhere
> what "b label;something" is supposed to do - so that is left
> unspecified, and operating systems are free to implement and
> document an extension.
>
> By the way, we do have a case here of the specification looking
> slightly ill-designed: "s///w filename;something" is explicitly
> marked as undefined, whereas the even simpler "w filename;something"
> is merely left unspecified.  But fortunately, we are not planning
> to change the behaviour of "[s///]w filename;something", so we don't
> need to worry about that right now.
>
>
> All that said, i see a few problems with the manual page, so here is
> a patch to fix it.
>
> The information in the CAVEATS section is misplaced.  The purpose
> of that section is to warn about typical programming mistakes, not
> to explain what our implementation does nor to explain what the
> standard requires.  Besides, it is wrong, semicolons *can* be used
> after "b" and "t" with our implementation.  Finally, the current
> wording can mislead people to think this might be forbidden:
>
>   $ echo "A\nB" | sed '=;r suffix.txt'
>
>
> So move the information about "a", "c", "i", "r", and "w" to the
> DESCRIPTION.  I don't think it belongs into the second paragraph
> from the top; even though that is where ";" is introduced, that
> place would be way too prominent.  Below "SED FUNCTIONS", where
> other special properties of groups of functions are also explained,
> seems about right.
>
> Move the information about "b", "t", and ":" to STANDARDS where it
> belongs.  That commands in general can be separated with ";" was
> already said at the very top of the page.
>
> I don't think anything more needs to be said about "#".
> We already have:
>
>     The '#' and the remainder of the line are ignored (treated as a
>     comment), with the single exception that if the first two
>     characters in the file are '#n', the default output is
>     [...]
>
> It's kind of obvious the remainder of the line may contain ';'
> and it will be ignored.
>
> While here, avoid "permitted" - were aren't planning to send anybody
> to jail for sed(1) abuse.
>
> OK?
>   Ingo
>

hi.

it reads ok to me. but just to note - there is nothing wrong with the
way "permitted" is used in that text.

jmc

>
> Index: sed.1
> ===================================================================
> RCS file: /cvs/src/usr.bin/sed/sed.1,v
> retrieving revision 1.57
> diff -u -r1.57 sed.1
> --- sed.1 14 Nov 2018 10:59:33 -0000 1.57
> +++ sed.1 7 Dec 2018 16:48:14 -0000
> @@ -277,6 +277,20 @@
>  The synopses below indicate which arguments have to be separated from
>  the function letters by whitespace characters.
>  .Pp
> +The
> +.Ic a ,
> +.Ic c ,
> +.Ic i ,
> +.Ic r ,
> +and
> +.Ic w
> +functions cannot be followed by another command separated with a semicolon.
> +The
> +.Ar text
> +and
> +.Ar file
> +arguments may contain semicolon characters.
> +.Pp
>  Functions can be combined to form a
>  .Em function list ,
>  a list of
> @@ -561,6 +575,14 @@
>  .Op Fl aEiru
>  are extensions to that specification.
>  .Pp
> +Following the
> +.Ic b ,
> +.Ic t ,
> +or
> +.Ic \&:
> +commands with a semicolon and another command is an extension to the
> +specification.
> +.Pp
>  The use of newlines to separate multiple commands on the command line
>  is non-portable;
>  the use of newlines to separate multiple commands within a command file
> @@ -571,11 +593,3 @@
>  .Nm
>  command appeared in
>  .At v7 .
> -.Sh CAVEATS
> -The use of semicolons to separate multiple commands
> -is not permitted for the following commands:
> -.Ic a , b , c ,
> -.Ic i , r , t ,
> -.Ic w , \&: ,
> -and
> -.Ic # .
>