Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH: complete probes for dtrace completion

Jun T wrote:
> I tested on macOS.


> It is not filtered out due to a typo;  'pattern' in ${${...}:#pattern}
> needs a trailing '*'.

Ah, good point, thanks.

> On macOS, output of 'dtrace -l' includes lines like
>  170    syscall            #8 entry

I get those on FreeBSD too but hadn't especially paid much attention.
Trying to specify them only produces an error so filtering is likely

> And dtrace on macOS always issues waring like
> dtrace: system integrity protection is on, some features will not be available
> We need to send it to /dev/null.

Since 5.0.8, _call_program sends stderr to /dev/null by default and
requires 2>&1 to preserve it. Were you actually getting the errors
dumped from _dtrace?

> Yes. And I also added options listed in the online document for
> Solaris 11.4:

Looks good, thanks.

> There is a dtrace command in systemtap-sdt-{dev,devel} package for
> {Debian,RedHat}-like systems (but I have never used it):

> https://manpages.debian.org/buster/systemtap-sdt-dev/dtrace.1.en.html

> I'm not sure _dtrace needs to support it.

I have used dtrace on Linux in the past but there were more occasions
where I moved over to a Solaris machine to use it. I'm not sure whether
the latest is still systemtap based. bpftrace has improved and looks to
be very similar. I've heard a Windows port exists too. I doubt _dtrace
would need much if any changes for the Linux port. I don't think it is
vital to add support but also see no reason not to. Would be better to
check the latest release on Oracle Linux rather than that old man page,
however. There's also a NetBSD port but I doubt that deviates much, if
at all.


Messages sorted by: Reverse Date, Date, Thread, Author