@adamralph Is this just console messages or all log messages? We currently
have -loglevel for setting log levels. If the param is named -logfile I'd
expect that all log entries would get written here.

On Sun, Apr 27, 2014 at 5:53 PM, Adam Ralph notifications@github.comwrote:

FWIW

This has proven invaluable to me in developing Bau today. In the Bau
acceptance tests I shell out scriptcs.exe and by passing this switch I can
log out the console and debug things.

In REPL, it also picks up both input and output which is kind of cool.
Could be quite a useful diagnostic tool when people have issues, i.e. they
can log the console whilst reproducing the issue or we can request that
they do it.

[image: image]https://cloud.githubusercontent.com/assets/677704/2812782/d7cbb4b2-ce6e-11e3-8b88-8f502ec9f10f.png

[image: image]https://cloud.githubusercontent.com/assets/677704/2812783/dac64bc8-ce6e-11e3-99ce-253e839ff87a.png

You can merge this Pull Request by running

git pull https://github.com/adamralph/scriptcs logfile

Or view, comment on, or merge it at:

#637
Commit Summary

• adds a -logfile switch for mirroring all console messages to a file

File Changes

• A src/ScriptCs.Hosting/FileLoggerConsole.cshttps://github.com/Option for mirroring all console rendering in a file #637/files#diff-0(80)
• M src/ScriptCs.Hosting/ScriptCs.Hosting.csprojhttps://github.com/Option for mirroring all console rendering in a file #637/files#diff-1(1)
• M src/ScriptCs/Program.cshttps://github.com/Option for mirroring all console rendering in a file #637/files#diff-2(8)
• M src/ScriptCs/ScriptCsArgs.cshttps://github.com/Option for mirroring all console rendering in a file #637/files#diff-3(3)

Patch Links:

• https://github.com/scriptcs/scriptcs/pull/637.patch
• https://github.com/scriptcs/scriptcs/pull/637.diff

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/637
.

@glennblock yes, it's all log messages. In scriptcs.exe there is effectively no difference between log and console since we don't add a common.logging adapter. We just intercept all logging calls and push them through the configured IConsole, according to the loglevel switch.

If anything, the resulting file contains extra artifacts which a pure log file shouldn't, i.e. the command prompt and an echo of command input. Perhaps we could come up with a more accurate name which reflects that?

With -loglevel DEBUG:

this is a good change but I think the name is misleading. should be something like -output or something like that, since it's not just log

I agree. Any advances on -output? I have to leave shortly for the rest of the day. Unless someone comes up with a better name I'll change it to -output when I get back.

-consolefile?

It's not just output, it's input too. It's the whole console.

I could also change the name of the type (FileLoggerConsole) to remove any reference to logging. Initially I had it as FileWritingConsole. I could change it back, or just call it FileConsole.

@adamralph let's get this in. Can you change it to -output?

Thanks Glenn,

I see this feature as nice method for someone using the REPL to capture their thought process while they're working to later reference.

@glennblock sure, will do

For some reason it blows up after rebasing off latest dev when I try to invoke it for REPL.

I think I may have been using different command line params when I tested it previously but in honesty I can't figure out how it ever worked. I think it boils down to the fact that we special case certain params when no script path is passed. I'll try and figure things out in ArgumentParser but I'm finding the logic difficult to follow. It may be good to do some refactoring here.

what's the error?
there were just a few changes over the last week - so it should be easy to isolate

The command factory never falls into any of the cases so it defaults to show usage.

what are you passing in?

-logfile scriptcs.log

if you want a repl you need to add -repl

REPL will only be opened if you don't have any args or only pass -log <level>. Log arg is explicitly whitelisted to trigger REPL if it's the only arg

Ah of course, thanks! 😅

It's a bit weird from a user perspective, i.e. I type scriptcs and I get REPL, I want to get output in a file but scriptcs -output f.log blows up. I'll leave it as is right now but I think it may be worth revisiting the shape of our args at some stage. I know we've already talked about changing to commands instead of switches for things like repl, install, save, etc. so should take this into consideration then.

Rebased and changed from -logfile to -output.

Should be ready to go.

Just want to add my thoughts from a discussion earlier today. I still think it would be nice to be able to use a REPL command (#612) to output to a file.

The scenario I'm thinking of would be if you have just done some work in the REPL but haven't started the REPL with output f.log. Then you could just type something like :output f.log in the REPL.

This could even be extended to:
:output commands f.log - output only commands issued in REPL to the log file
:output outputs f.log - output only output entries to the log file

Not sure if this could leverage this existing PR as a starting point. My only concern with this REPL command approach is that everything will have to be held in some form of in-memory collection by default even if the user has no intention of logging to file. Not sure if this is an issue - there is unlikely to be enough in the collection to cause memory pressure ... famous last words

That's an interesting idea @paulbouwer. I've spun it off into an issue of it's own #657

I don't think this PR can be used as a base as the -output switch is a much simpler concept. The REPL command, as you indicate, will have to be more involved, storing history etc. and I think it can exist independently from the -output switch.

Given the proposed REPL command functionality, it would be very easy to
implement it as a REPL command too
#612

Just implement IReplCommand that takes the file as param and the output
type, and set a custom console on the REPL that writes each command to a
file
It could be append-only file, if you are concerned with memory usage.
Console on the REPL currently has a private setter so that would need to be
changed.

On 5 May 2014 10:50, Paul Bouwer notifications@github.com wrote:

Just want to add my thoughts from a discussion earlier today. I still
think it would be nice to be able to use a REPL command (#612#612)
to output to a file.

The scenario I'm thinking of would be if you have just done some work in
the REPL but haven't started the REPL with output f.log. Then you could
just type something like :output f.log in the REPL.

This could even be extended to:
:output commands f.log - output only commands issued in REPL to the log
file
:output outputs f.log - output only output entries to the log file

Not sure if this could leverage this existing PR as a starting point. My
only concern with this REPL command approach is that everything will have
to be held in some form of in-memory collection by default even if the user
has no intention of logging to file. Not sure if this is an issue - there
is unlikely to be enough in the collection to cause memory pressure ... famous
last words

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/637#issuecomment-42169121
.

Cool, so I guess once this PR goes in, that command can reuse the FileConsole that this PR introduces.

Sounds good.

Rebased and updated for PowerArgs 2.0.

great - thanks