I intend to use PuTTYTray with MTPuTTY, which can create virtuals sessions on one real PuTTY session, containing for exemple default settings (font, size, ..), but I'd like to set the log file individually for each session using arguments.
KiTTY is able to do that (and it seems to be the only one :( ) but it is a bit too much in feature for me.
Could you implement a -log command line option that allow to override the log file contained in the session ?
Ex: putty.exe -load "!Défaut" -log myserver.log my.server.net
GH-97: -title, -log, etc. options from KiTTY
Note to self: These are implemented in cmdline.c, not directly in window.c like KiTTY.
Why are these being forced along with setting the log filename?
conf_set_int(conf, CONF_logtype, 1);
conf_set_int(conf, CONF_logxfovr, 1);
conf_set_int(conf, CONF_logflush, 1);
I just did what KiTTY was doing.
Turning the logging on makes sense... if you're assuming it's overriding the default settings, and that the logging is off. Perhaps it should set the logtype only if the logtype is off?
Otherwise the parameter does nothing when the logging is disabled, which doesn't seem like what people would expect.
I'm not sure what I feel about overwrite and flush. Maybe the intention here is to have it act like app > logfile.log would for typical shells.
app > logfile.log
I don't see why overwrite should be forced ; if my template/filename is wrong I'd rather have my log file "corrupted" with new data appended than completly overwrited ;)
Simplest should be no to force this.
But I don't see why the 2 others should be forced too, if I want to log "ssh packets" it seems impossible using -log.
Maybe you could also make a -logfile option that only change the log location but keeps other settings untouched from the session ?
Anyway thank you, will you release soon a release including this ?
I don't know if you still have notifications in this issue @FauxFaux , but could you correct the behaviour of this option ?
Maybe I could write a patch for this.
Merge pull request #172 from Alex131089/GH-171
Correct "-log" behaviour (cf #97 )