Bug #10170
closedDebug commands raise when no debug.log exists
100%
Description
In a default user scenario on Mac, no debug.log file is created here:
https://github.com/kk7ds/chirp/blob/py3/chirp/logger.py#L89
unless CHIRP_DEBUG_LOG has been set in the environment.
The debug-related menu items here:
https://github.com/kk7ds/chirp/blob/py3/chirp/wxui/main.py#L1107
https://github.com/kk7ds/chirp/blob/py3/chirp/wxui/main.py#L1117
do not check for the existence of debug.log before attempting to copy it using shutil.copy() , leading to, for example:
ERROR: <function ChirpMain._menu_debug_loc at 0x113e09620> raised unexpected exception
Traceback (most recent call last):
File "/Users/martinc/dev/src/github/chirp/chirp/wxui/common.py", line 408, in run_safe
return fn(*args, **kwargs)
File "/Users/martinc/dev/src/github/chirp/chirp/wxui/main.py", line 1123, in _menu_debug_loc
shutil.copy(src, dst)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/shutil.py", line 241, in copy
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/shutil.py", line 120, in copyfile
with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: '/Users/martinc/.chirp/debug.log'
I'm filing a ticket rather than a PR, since it's unclear to me as to the best way to address this.
Updated by Dan Smith about 2 years ago
The intent is to always write the debug log to that location, so that's probably the actual fix, although it seems to be working for me on macos.
But obviously it shouldn't fail if it's not there, so I'll look at that too.
Updated by Dan Smith about 2 years ago
You said "default user scenario" but did you mean "when I run it from a terminal"? The frozen and/or tty checks there should result in a debug log being written for "normal users".
If so, I think the fix is just to not expose those menu elements if the debug log doesn't exist, which would only happen for developer types who are running if from the command-line.
Updated by Dan Smith about 2 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|a439205cbe443a320edeff7273fc884973b775c8.
Updated by Martin Cooper about 2 years ago
Ah, you're right, I'm running from a terminal, and starting Chirp from within my git tree. (As with most devs, I suspect, I don't do an actual build.)
There is one other quirk to consider. If I set CHIRP_LOG, so that I get both console and file logging, the commands would make sense. However, they'll only work if I happen to set CHIRP_LOG to where Chirp thinks a log file should be. If I set it to somewhere else, I will have a log file, but the commands to view it from within Chirp won't work. Admittedly, since I also have console output, it may not make much sense to use the commands, but just thought I'd mention it.
Updated by Dan Smith about 2 years ago
Actually, I think you'll get debug.log in the usual place and your other log, won't you? I'm setting "has_debug_log_file" only if we're writing to the usual location, and that's what I'm using to key the presence of the menu items.
Or are you saying you want the menu items to work even if we're logging to the additional location specified by CHIRP_LOG? Either way, I guess I expect anyone tweaking that level of detail to not be all that interested in the menu items, but feel free to revise that further if you want. Probably the only time I as a developer care about it for my own stuff is windows because I can't easily less the log myself from a terminal :)
Updated by Dan Smith about 2 years ago
Sorry, to clarify I meant you'll get both if you run with CHIRP_LOG no tty. My point was, I don't think you'll get the menu items pointing at a stale debug.log ever. If they're there, they'll point to the active one.
Updated by Martin Cooper about 2 years ago
What you've done is fine. I was thinking that maybe the commands should show the log from CHIRP_LOG if there's no regular debug.log, but on second thoughts that's really not useful. I set CHIRP_LOG when I want a record of what I'm seeing in the console, when I want to be able to copy / paste some of it elsewhere later. In that scenario, there's no particularly good reason to use GUI commands to open the log file.