Re: sed(1) and line number 0
On Sun, Aug 15, 2021 at 09:52:57PM +0200, Martijn van Duren wrote:
> On Sat, 2021-08-14 at 20:20 +0200, Andreas Kusalananda Kähäri wrote:
> > On Fri, Aug 13, 2021 at 11:19:16PM +0800, Philippe Meunier wrote:
> > > Hello,
> > >
> > > While porting a shell script from Linux to OpenBSD I came across the
> > > following:
> > [cut]
> > > 2) Out of curiosity, is there an OpenBSD equivalent to GNU's
> > > '0,/^test$/d' ?
> >
> > As far as I can see, the following would work the same as GNU's
> > '0,/^test$/d':
> >
> > sed -e '1 { /^test$/d; }' -e '1,/^test$/d' file
> >
> > That is, delete the first line if it is "test", otherwise delete from
> > line 1 the next line that is "test".
> >
> This behaviour should not be relied upon for portable scripts, since
> addresses in combination with "next cycle" are heavily underspecified
> and at least doesn't match gsed's behaviour:
Lucky me that what was being sought was an expression that worked with
the OpenBSD sed implementation. Interestingly, it also works with the
Plan 9 sed. It doesn't make it more correct, that's true, but it makes
GNU sed the odd one out.
> $ printf 'test1\nbla1\ntest2\nbla2\n' | gsed -e '1 { /^test/d; }' -e
> '1,/^test/d'
> bla2
>
> Right now, I can't for the life of me think of a shorter way to do this
> portably, but the code below works in both sed and gsed.
> $ printf 'bla0\ntest1\nbla1\ntest2\nbla2\n' | sed
> '1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
> bla1
> test2
> bla2
> $ printf 'bla0\ntest1\nbla1\ntest2\nbla2\n' | gsed
> '1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
> bla1
> test2
> bla2
> $ printf 'test1\nbla1\ntest2\nbla2\n' | sed
> '1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
> bla1
> test2
> bla2
> $ printf 'test1\nbla1\ntest2\nbla2\n' | gsed
> '1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
> bla1
> test2
> bla2
> If you need this snippet in a larger script that needs the holdspace,
> make sure that you clean the holdspace before continuing.
>
> martijn@
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: sed(1) and line number 0
On Sat, 2021-08-14 at 20:20 +0200, Andreas Kusalananda Kähäri wrote:
> On Fri, Aug 13, 2021 at 11:19:16PM +0800, Philippe Meunier wrote:
> > Hello,
> >
> > While porting a shell script from Linux to OpenBSD I came across the
> > following:
> [cut]
> > 2) Out of curiosity, is there an OpenBSD equivalent to GNU's '0,/^test$/d' ?
>
> As far as I can see, the following would work the same as GNU's '0,/^test$/d':
>
> sed -e '1 { /^test$/d; }' -e '1,/^test$/d' file
>
> That is, delete the first line if it is "test", otherwise delete from
> line 1 the next line that is "test".
>
This behaviour should not be relied upon for portable scripts, since
addresses in combination with "next cycle" are heavily underspecified
and at least doesn't match gsed's behaviour:
$ printf 'test1\nbla1\ntest2\nbla2\n' | gsed -e '1 { /^test/d; }' -e
'1,/^test/d'
bla2
Right now, I can't for the life of me think of a shorter way to do this
portably, but the code below works in both sed and gsed.
$ printf 'bla0\ntest1\nbla1\ntest2\nbla2\n' | sed
'1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
bla1
test2
bla2
$ printf 'bla0\ntest1\nbla1\ntest2\nbla2\n' | gsed
'1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
bla1
test2
bla2
$ printf 'test1\nbla1\ntest2\nbla2\n' | sed
'1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
bla1
test2
bla2
$ printf 'test1\nbla1\ntest2\nbla2\n' | gsed
'1{/^test/{h;d;};};1,/^test/{x;/^$/{x;d;};x;}'
bla1
test2
bla2
If you need this snippet in a larger script that needs the holdspace,
make sure that you clean the holdspace before continuing.
martijn@
Re: wait returns 127 for existing process?
On Sun, Aug 15, 2021 at 07:23:53PM +0200, Claus Assmann wrote: > On Sun, Aug 15, 2021, Andreas Kusalananda Khri wrote: > > > wait returns 127 if the process is not a child of the current shell. > > Is it a child process of the current shell? If so, does it install a > > Yes, indirectly via 2-3 sh scripts. Yeah, that won't work. wait only works for child processes of the current shell, not for grand-child processes etc. > > signal handler for the HUP signal? > > Yes, the "usual" one for a multi-threaded process: one thread which > handles signals and sends a single byte via a pipe to another thread > which then (hopefully) does the appropriate thing. > > So it seems better to use kill -0 PID to see whether the process > still exists. Yes, if you have the PID for it, otherwise pkill -0 with the apropriate options and pattern to pick the correct process out. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: wait returns 127 for existing process?
On Sun, Aug 15, 2021, Andreas Kusalananda Khri wrote: > wait returns 127 if the process is not a child of the current shell. > Is it a child process of the current shell? If so, does it install a Yes, indirectly via 2-3 sh scripts. > signal handler for the HUP signal? Yes, the "usual" one for a multi-threaded process: one thread which handles signals and sends a single byte via a pipe to another thread which then (hopefully) does the appropriate thing. So it seems better to use kill -0 PID to see whether the process still exists. -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: wait returns 127 for existing process?
On Sun, Aug 15 2021, Claus Assmann wrote: > I must misunderstand something about wait (sh command), but I'm not > sure what: why does wait return 127 for an existing process? > > $ PM=31309;kill -HUP $PM; echo $?; ps -p $PM; wait $PM; echo $?; ps -p $PM > 0 > PID TT STATTIME COMMAND > 31309 p0 S0:00.03 ../libpmilter/t-pmilter-1 -r m=550 > 127 > PID TT STATTIME COMMAND > 31309 p0 S0:00.03 ../libpmilter/t-pmilter-1 -r m=550 > $ wait $PM; echo $? > 127 > $ kill -0 $PM;echo $? > 0 > > (OpenBSD 6.8) > > I guess the (multi-threaded) process is in some "weird" state? I think Andreas provided a good answer already, > PS: it seems I can't attach a debugger either: > $ egdb -p $PM ../libpmilter/t-pmilter-0 > GNU gdb (GDB) 7.12.1 > ... > Reading symbols from ../libpmilter/t-pmilter-0...done. > Attaching to program: /home/ca/sm-9/openbsd-111/libpmilter/t-pmilter-0, > process 31309 > ptrace: Operation not permitted. About this one: revision 1.66 date: 2014/12/12 07:45:46; author: tedu; state: Exp; lines: +9 -1; commitid: tOiu53jgNjU0V5Os; sysctl kern.global_ptrace. controls whether you can ptrace any process with appropriate privileges or only one own's children. ok deraadt -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: wait returns 127 for existing process?
On Sun, Aug 15, 2021 at 10:57:33AM +0200, Claus Assmann wrote: > I must misunderstand something about wait (sh command), but I'm not > sure what: why does wait return 127 for an existing process? > > $ PM=31309;kill -HUP $PM; echo $?; ps -p $PM; wait $PM; echo $?; ps -p $PM > 0 > PID TT STATTIME COMMAND > 31309 p0 S0:00.03 ../libpmilter/t-pmilter-1 -r m=550 > 127 > PID TT STATTIME COMMAND > 31309 p0 S0:00.03 ../libpmilter/t-pmilter-1 -r m=550 > $ wait $PM; echo $? > 127 > $ kill -0 $PM;echo $? > 0 wait returns 127 if the process is not a child of the current shell. Is it a child process of the current shell? If so, does it install a signal handler for the HUP signal? -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
wait returns 127 for existing process?
I must misunderstand something about wait (sh command), but I'm not sure what: why does wait return 127 for an existing process? $ PM=31309;kill -HUP $PM; echo $?; ps -p $PM; wait $PM; echo $?; ps -p $PM 0 PID TT STATTIME COMMAND 31309 p0 S0:00.03 ../libpmilter/t-pmilter-1 -r m=550 127 PID TT STATTIME COMMAND 31309 p0 S0:00.03 ../libpmilter/t-pmilter-1 -r m=550 $ wait $PM; echo $? 127 $ kill -0 $PM;echo $? 0 (OpenBSD 6.8) I guess the (multi-threaded) process is in some "weird" state? PS: it seems I can't attach a debugger either: $ egdb -p $PM ../libpmilter/t-pmilter-0 GNU gdb (GDB) 7.12.1 ... Reading symbols from ../libpmilter/t-pmilter-0...done. Attaching to program: /home/ca/sm-9/openbsd-111/libpmilter/t-pmilter-0, process 31309 ptrace: Operation not permitted. PPS: the problem is extremely hard to reproduce: running the single functional test never causes the problem, so far it happens only if many other tests have been run before (which takes almost 2 hours). -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: using mdnsd as resolver
On 2021-08-14, Björn Gohla wrote: > hi all, > > i'm trying to use openmdns to find my network printer. it shows up > (sporadically) when i run > > $ mdnsctl browse -r > > and i can obtain the address using > > $ mdnsctl lookup EPSON892A3E.local > > but how do i integrate the mdns daemon into resolv.conf? the man pages > certainly don't mention how to do it. > > i would expect gethostbyname(3) to be able to resolve EPSON892A3E.local There isn't any support for gethostbyname looking up mdns records. Perhaps there is some software that can take a normal DNS query and use mdns for looking it up which might worm - a quick google finds something written in node.js, maybe there's another in a less annoying language too! I would recommend just making a DHCP assignment or using a static address for your printer though. -- Please keep replies on the mailing list.
