[texshop] Console Problem(?)

[Bruno Voisin]

> Le 5 déc. 2018 à 01:59, Gary L. Gray <glgray at me.com> a écrit :
> 
>> On Dec 4, 2018, at 7:52 PM, Richard Koch <koch at uoregon.edu> wrote:
>> 
>> Thanks very much. Now I wonder if you have a crash report from pdflatex, or a report in a system log or something like that.
>> 
>> Very helpful information..
> 
> Looking through Console I don't find anything pdflatex related, but there is a lot of stuff in there. I also see nothing in the system log at the time it occurred. Sorry.

The Console app changed fundamentally a few macOS versions ago. Now I can't find my way through it any longer; namely, figure out which log file to look at and how.

Back three months ago, when facing problems with a Time Machine backup disk, I looked harder and found a couple of web pages, ended up with the following instructions for Time Machine, to be used in Terminal:


Stream the log, live (like tail):

log stream --style syslog  --predicate 'senderImagePath contains[cd] "TimeMachine"' --info

Don't stream, but show the log end exit:

log show --style syslog  --predicate 'senderImagePath contains[cd] "TimeMachine"' --info


I wrote them into a file then, but didn't note or bookmarked the pages where I had found them. Bad idea!

Going through my Safari browsing history for the day at which the file was created, it seems the pages were  

https://eclecticlight.co/2016/09/29/welcome-to-macos-sierras-new-console-its-buried-in-terminal/
https://apple.stackexchange.com/questions/258325/macos-new-logging-api-unified-logging-log-stream

https://superuser.com/questions/1126990/how-to-view-time-machine-log-in-macos-sierra
https://apple.stackexchange.com/questions/302486/accessing-time-machine-console-messages

If I understand correctly, in the "new" (ie Sierra and above) Console app, system logs are no longer written to a file  but are streamed continuously to the app, where they are also mixed with RAM messages. As a result, to consult them and filter those relevant to a particular app or process, you have to use the log utility in Terminal.

It then seems down to finding the correct --predicate option for the problem at hand. I just tried what I could think of for TeXShop, based on the above pages, but it returned nothing, probably because I haven't used TeXshop for several days:

$ log show --predicate 'subsystem == "TeXShop"' --info
Filtering the log data using "subsystem == "TeXShop""
Skipping debug messages, pass --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL  
--------------------------------------------------------------------------------------------------------------------
Log      - Default:          0, Info:                0, Debug:             0, Error:          0, Fault:          0
Activity - Create:           0, Transition:          0, Actions:           0

and same with

log show --predicate 'subsystem == "edu.uo.texshop"' --info

What seems needed is to find the relevant --predicate. Is it for TeXShop or pdflatex, namely is it pdflatex which is crashing silently or the communication with TeXShop that does? Based on your log and observation that typesetting does not stop, it seems the culprit is pdflatex.

You might try

log show --predicate 'process == "pdflatex"' --info

but I've no idea whether that would work.

The man page for log has a whole section on predicates:


PREDICATE-BASED FILTERING
     Using predicate-based filters via the --predicate option allows users to
     focus on messages based on the provided filter criteria.  For detailed
     information on the use of predicate based filtering, please refer to the
     Predicate Programming Guide:
           https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html

     The filter argument defines one or more pattern clauses following NSPred-
     icate rules.  Supported keys include:

     eventType          The type of event: activityCreateEvent, activityTran-
                        sitionEvent, logEvent, signpostEvent, stateEvent,
                        timesyncEvent, traceEvent and userActionEvent.

     eventMessage       The pattern within the message text, or activity name
                        of a log/trace entry.

     messageType        For logEvent and traceEvent, the type of the message
                        itself: default, info, debug, error or fault.

     process            The name of the process the originated the event.

     processImagePath   The full path of the process that originated the
                        event.

     sender             The name of the library, framework, kernel extension,
                        or mach-o image, that originated the event.

     senderImagePath    The full path of the library, framework, kernel exten-
                        sion, or mach-o image, that originated the event.

     subsystem          The subsystem used to log an event.  Only works with
                        log messages generated with os_log(3) APIs.

     category           The category used to log an event.  Only works with
                        log messages generated with os_log(3) APIs.  When cat-
                        egory is used, the subsystem filter should also be
                        provided.


which is followed by examples.

Not sure the above helps at all. I hope it might.

Bruno