Mac - launching System_Profiler from Wish on El Capitain

[daneyul]

Can anyone shed any light on why:

exec system_profiler

on Mac OSX 10.11 (El Capitan) invariably exits with "child killed:kill signal". (I can exec it with the -usage arg to get usage info, but if it tries to deliver a report I get that error). Tried with both Wish 8.5.9 and 8.6.9.1

On Sierra, High Sierra and Mojave the same command works fine, delivering me a report.

So far I've tried on two 10.11 systems.

"Open |[list system_profiler]" also fails (immediate EOF) on 10.11, but works on the other systems. (Just running system_profiler in a bash terminal works fine.)

Just trying to figure out what's special about that process on El Capitan.

[Rich]

daneyul <dane...@gmail.com> wrote:
> Can anyone shed any light on why:
>
> exec system_profiler

Does OSX have an strace command (or the fancier BSD 'tracing' command
of which I don't remember the name because I don't have a BSD or Mac
system)?

If yes to either, you could try tracing the exec and see what is
happening on a very low level (and sometimes this sheds light on a
cause).

> "Open |[list system_profiler]" also fails (immediate EOF) on 10.11,
> but works on the other systems. (Just running system_profiler in a
> bash terminal works fine.)

This implies that something is different in the environment underwhich
system_profiler is run between launching it from Tcl vs. launching it
from bash (i.e., one or more environment variables it uses are present
under bash, but not under Tcl's exec).

This effect you describe here is quite common with Cron jobs, where a
script works perfectly called from a user session from bash, but fails
when run as a cron job, because the PATH or some other environment
variable is different under both.

Figuring out which can be a pain sometimes, although differences in the
PATI variable would be the first suspect to investigate.

You could try using bash from Tcl to launch it, launch bash with the -c
option and then the command:

bash -c system_profiler
or

/bin/bash -c /usr/bin/system_profiler

Change /bin/ and /usr/bin/ to the actual disk locations on OSX for
either.

[Brad Lanam]

On Friday, September 20, 2019 at 2:18:27 PM UTC-7, Rich wrote:

> daneyul wrote:
> > Can anyone shed any light on why:
> >
> > exec system_profiler
>
> Does OSX have an strace command (or the fancier BSD 'tracing' command
> of which I don't remember the name because I don't have a BSD or Mac
> system)?

It has dtrace, a specific subset of dtruss.

[daneyul]

Thanks!

When I try to execute "exec dtrace system_profile" I get:
dtrace: failed to initialize dtrace: DTrace requires additional privileges

I then tried it with sudo, and it worked--but then the system_profile command did too! Which means I got no trace info from the actual problem. But... that did lead me to realize that I can launch the system profiler with "echo $password | sudo -S system_profile" via Wish and it works. So, to get by I'm going to force a password prompt in my script and run the above, but it's odd that only El Capitan requires it.

I did TRY setting the path in my TCL console, BTW--as it was slightly different than that of my Bash shell (which can launch System_profile without sudo) but it seemed to make no difference. Setting the PATH was confusing. Couldn't get "bash -c export PATH=..." to work. "Command not found." The method that seemed to set the PATH was to just construct it like this and then launch the profiler in the same line:
exec "bash -c PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin;system_profiler" but does that actually modify the PATH for the shell the system_profiler command runs in?

I do run my Wish environment with "Embedded" stand-alone Wish apps, BTW.

[Brad Lanam]

You could try:

exec "bash -c PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin;export PATH;system_profiler"

or:

set ::env(PATH) /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
exec system_profiler