Hi Andy, > I mean that there are similar functionality in different tools and for > one purpose you need one, for another another and there is no format > file convertors available (as far as my shallow googling shows). Yes, this is a truth I can't change. So, I chose the Free Software solution, so the format is at least documented. Also, you could just try sigrok and pulseview, it has a nice set of protocol decoders. GTKWave should be able to use the binary data inside the .sr IIRC. For other software, you can at least write a converter because the format is open. > > In your V1 review, you suggested -ENODATA. I will pick yet another one, > > but it really matters zero in practice. > > Ah, okay, then choose the one you think fits most. I took -EBADR now. > > What is the difference? Does it matter here? > > I'm a bit lost in the context here, but the ' > /dev/null 2>&1' means > to redirect stdout to the /dev/null followed by redirecting stderr to > stdout (which is redirected to /dev/null). The other construction > might have side effects IIRC. Andy, *if* there is a side effect, I will happily fix it. But "it might have a side effect IIRC" leaves all the detective work to me and I am not short of other action items. Especially because this is not a critical path. > > I read that '-a' and '-o' are deprecated. Dunno where but looking again > > I found this: https://stackoverflow.com/questions/20449680/boolean-operators-a-o-in-bash > > The SO talks about _bash_, your script is a plain Shell one, right? It talks about being deprecated in POSIX, so quite the opposite of a bashism, I'd say. > > > > + taskset "$1" echo 1 > "$lasysfsdir"/capture || fail "Capture error! Check kernel log" > > > > > > Shouldn't this function setup signal TRAPs? > > > > To do what? > > To clean up the garbage it may leave in case of the interrupted run, no? I don't see any? Which ones do you have in mind? > > > $@ is better, actually one should never use $*. > > > > What difference does it make when expanding into a string? > > The difference is on how the "foo bar" (with double quotes!) will be > represented. In your case it will be translated as "foo" and "bar", in > the case I'm saying it will be "foo bar". I very well know the difference. I was interested in what difference you see when they get expanded into a string? Happy hacking, Wolfram
Attachment:
signature.asc
Description: PGP signature
