New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write Text to Console Programmatically #3

Closed
hypersw opened this Issue Dec 15, 2015 · 29 comments

Comments

Projects
None yet
2 participants
@hypersw
Collaborator

hypersw commented Dec 15, 2015

Here I mean not stdin but emulating stdout, as if the program has written smth to the console, as the "second stream".

99% cases would probably be:

  1. Write out smth before the console payload process runs.

(which means this has to be set up in conemu cmdline or better settings XML, because otherwise we can't guarantee the greeting goes before the payload text)

  1. Write out smth after it terminates.

(which can be set up as customizing the conemuc's "press esc or enter" text, also has to be done before starting)

These two could be seen in wide use e.g. in GitExtensions in the console windows I'm currently in process of upgrading.

Writing smth in the process might also be useful (e.g. we parsed the stage out of the stream and want to comment on it), but is much less critical.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Dec 15, 2015

Owner

The solution may be either simple or complicated.

Actually, I think that greetings message may differ my shell/Task. So, probably the best way is adding something like type "bla-bla-bla.txt" & to Task contents. Alternatives: ConEmuC -t "file" &, ConEmuC -e "string with escapes" &.

Final message... Well, may be it may be implemented as -cur_console:c:"Your final message". Yep, it may depends on shell/Task too.

Printing while process is running? Hmm... That may harm running process output, or may be overwritten by processes in next second.
Well, there's no problem to implement something like Write("bla-bla-bla") GuiMacro, but where you'll write it?
Above cursor? It may overwrite process output.
Below cursor? Process may go next line next second and overwrite this text.

Owner

Maximus5 commented Dec 15, 2015

The solution may be either simple or complicated.

Actually, I think that greetings message may differ my shell/Task. So, probably the best way is adding something like type "bla-bla-bla.txt" & to Task contents. Alternatives: ConEmuC -t "file" &, ConEmuC -e "string with escapes" &.

Final message... Well, may be it may be implemented as -cur_console:c:"Your final message". Yep, it may depends on shell/Task too.

Printing while process is running? Hmm... That may harm running process output, or may be overwritten by processes in next second.
Well, there's no problem to implement something like Write("bla-bla-bla") GuiMacro, but where you'll write it?
Above cursor? It may overwrite process output.
Below cursor? Process may go next line next second and overwrite this text.

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 21, 2015

Collaborator
  1. How to pass the messages.
    I'd say that some out-of-cmdline method is a must because of:
    (a) cmdline string escaping which makes it complicated to pass arbitrary messages, even worse, it is irreversible with standard cmdline parsers;
    (b) there's a limit over the length of the cmdline, some payload processes might come close to that limit (java with its classpath is often at risk), so adding a lengthy text to the payload cmdline might go over the limit.
    So there should be a way to pass it in some file.

Intuitively I'd prefer the Settings.xml file. It's got StartTasksName and EnvironmentSet and probably smth else per-task. It's already being written to run conemu in the control, so this keeps the writing to the single file. Escaping is not a problem with XML.

Collaborator

hypersw commented Dec 21, 2015

  1. How to pass the messages.
    I'd say that some out-of-cmdline method is a must because of:
    (a) cmdline string escaping which makes it complicated to pass arbitrary messages, even worse, it is irreversible with standard cmdline parsers;
    (b) there's a limit over the length of the cmdline, some payload processes might come close to that limit (java with its classpath is often at risk), so adding a lengthy text to the payload cmdline might go over the limit.
    So there should be a way to pass it in some file.

Intuitively I'd prefer the Settings.xml file. It's got StartTasksName and EnvironmentSet and probably smth else per-task. It's already being written to run conemu in the control, so this keeps the writing to the single file. Escaping is not a problem with XML.

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 21, 2015

Collaborator
  1. Final message.
    Logically, and based on GE usages analysis, the final message might not be known until the payload process exits. At a minimum, it's "Done"/"Failed" based on the errorlevel, or some other info based on what the process has done.
    So I'd file it under "writing to the terminal stdout programmatically".
Collaborator

hypersw commented Dec 21, 2015

  1. Final message.
    Logically, and based on GE usages analysis, the final message might not be known until the payload process exits. At a minimum, it's "Done"/"Failed" based on the errorlevel, or some other info based on what the process has done.
    So I'd file it under "writing to the terminal stdout programmatically".
@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 21, 2015

Collaborator

2.1) Still need a way to suppress the standard message by -cur_console:c, of "… with ESC or Enter".

Collaborator

hypersw commented Dec 21, 2015

2.1) Still need a way to suppress the standard message by -cur_console:c, of "… with ESC or Enter".

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 21, 2015

Collaborator
  1. Writing to stdout.
    If it's possible to write to the terminal's stdout right the way the process itself would do it, then that's it.
    This decides on above/below caret question: just writes at the caret location and moves it. Looks as if you're doing printf from more than one thread.
    Yep might interfere with the process output, but let's assume the controlling app knows what it's doing and why. Parses process ANSI stream output, or detects some files written, and knows where to say the additional stuff. When the payload process has exited, for example. That's one useful thing to do.
Collaborator

hypersw commented Dec 21, 2015

  1. Writing to stdout.
    If it's possible to write to the terminal's stdout right the way the process itself would do it, then that's it.
    This decides on above/below caret question: just writes at the caret location and moves it. Looks as if you're doing printf from more than one thread.
    Yep might interfere with the process output, but let's assume the controlling app knows what it's doing and why. Parses process ANSI stream output, or detects some files written, and knows where to say the additional stuff. When the payload process has exited, for example. That's one useful thing to do.
@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Dec 21, 2015

Owner

OK, here is the concept:

  1. Implement switch -cur_console:c0 which would "Wait for ESC or ENTER", but without confirmation message.
  2. Implement GuiMacro Shell("cur_console",...) which would execute an application in the existing console. Of course, parent process must be aware of the consenquences. So, you would be able to run ConEmuC with switches -e or -t to print anything.
Owner

Maximus5 commented Dec 21, 2015

OK, here is the concept:

  1. Implement switch -cur_console:c0 which would "Wait for ESC or ENTER", but without confirmation message.
  2. Implement GuiMacro Shell("cur_console",...) which would execute an application in the existing console. Of course, parent process must be aware of the consenquences. So, you would be able to run ConEmuC with switches -e or -t to print anything.
@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 21, 2015

Collaborator
  1. Yep, that's good.
  2. So it's a recipe to spawn a conemuc process which will spawn another process (like cmd with type command) with its satellite processes like conhost, all to print a message to the stdout console file… well, If you say so…
  3. I've analyzed usages, in many of the cases the greeting is but echo of the command itself. Is it possible to make the terminal echo its task command into stdout before actually running it (much like ECHO ON would do)?
Collaborator

hypersw commented Dec 21, 2015

  1. Yep, that's good.
  2. So it's a recipe to spawn a conemuc process which will spawn another process (like cmd with type command) with its satellite processes like conhost, all to print a message to the stdout console file… well, If you say so…
  3. I've analyzed usages, in many of the cases the greeting is but echo of the command itself. Is it possible to make the terminal echo its task command into stdout before actually running it (much like ECHO ON would do)?
@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Dec 21, 2015

Owner
  1. Nope. ConEmuC has switches -echo and -type. Check docs. You would be able to execute it or new root process, I hope.
  2. This is not possible now. I don't think this feature must be deployed to end-users. On the contrary, they like "clean" terminal statup screen. But if you need to do some troubleshooting... I use ProcessExplorer to check ConEmuC startup command line.
Owner

Maximus5 commented Dec 21, 2015

  1. Nope. ConEmuC has switches -echo and -type. Check docs. You would be able to execute it or new root process, I hope.
  2. This is not possible now. I don't think this feature must be deployed to end-users. On the contrary, they like "clean" terminal statup screen. But if you need to do some troubleshooting... I use ProcessExplorer to check ConEmuC startup command line.
@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 22, 2015

Collaborator

On the “clean” terminal startup screen, are you sure? Here's the idea:
— If you want a built-in CMD in your app, then well, it's true. No use in its cmd echoed.
— But if you're inserting a terminal for running console commands (like, calling git, or THGW has a similar window for calling hg), then you most likely want to let user see the specific command the terminal is executing right now.
One reason is that all this red-eyed cmdline stuff is only vaguely integrated into GUI, often you have to go manually into command-line, for that it's very useful to see what the GUI app were trying to do in terms of command line, and why those error messages, for example.
Another reason is that unix-way utils are not very verbose on startup, won't say anything until there's an error or a result or a progress msg at least. So if you run git pull, first it goes connecting with the terminal window all blank for a while, you don't know if it's working or what. Same for git checkout. It's comforting if you see the command line written first. That's what I see by comparing old GE impl with the terminal-enabled one. So I think this is quite end-user (as an option on the control / conemu cmdline).

Collaborator

hypersw commented Dec 22, 2015

On the “clean” terminal startup screen, are you sure? Here's the idea:
— If you want a built-in CMD in your app, then well, it's true. No use in its cmd echoed.
— But if you're inserting a terminal for running console commands (like, calling git, or THGW has a similar window for calling hg), then you most likely want to let user see the specific command the terminal is executing right now.
One reason is that all this red-eyed cmdline stuff is only vaguely integrated into GUI, often you have to go manually into command-line, for that it's very useful to see what the GUI app were trying to do in terms of command line, and why those error messages, for example.
Another reason is that unix-way utils are not very verbose on startup, won't say anything until there's an error or a result or a progress msg at least. So if you run git pull, first it goes connecting with the terminal window all blank for a while, you don't know if it's working or what. Same for git checkout. It's comforting if you see the command line written first. That's what I see by comparing old GE impl with the terminal-enabled one. So I think this is quite end-user (as an option on the control / conemu cmdline).

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Dec 22, 2015

Owner

I'm lost. What is the suggestion?

Owner

Maximus5 commented Dec 22, 2015

I'm lost. What is the suggestion?

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 22, 2015

Collaborator

I'd suggest for adding a switch which makes ConEmu echo the payload command AS IS into the terminal before beginning to execute it. I can see this useful for one pattern of use for conemu-inside.

As for the -e | -t things, I'll try them as soon as we get the core nuget, with all the other features.

Collaborator

hypersw commented Dec 22, 2015

I'd suggest for adding a switch which makes ConEmu echo the payload command AS IS into the terminal before beginning to execute it. I can see this useful for one pattern of use for conemu-inside.

As for the -e | -t things, I'll try them as soon as we get the core nuget, with all the other features.

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Dec 24, 2015

Collaborator

c0/c/n choice implemented

Collaborator

hypersw commented Dec 24, 2015

c0/c/n choice implemented

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 15, 2016

Collaborator

We've been using GE with ConEmu since early January full-scale on the team. Can say it solves the original problem for sure, and works almost nicely. Thanks for help with the stuff.

There're, like, two noticeable glitches though, one of them is this one issue, for it is a slight regression from the original GE functionality.

I tried to play with -e/-t in December, but didn't think up a nice way. conemu.exe won't accept these switches, while calling conemuc is too late because the echoed cmdline has to be yielded before it starts to run. Maybe the idea was to run an empty terminal (with cmd), then use guimacro to write text, then use guimacro to invoke whatever command should be run for payload?

Collaborator

hypersw commented Feb 15, 2016

We've been using GE with ConEmu since early January full-scale on the team. Can say it solves the original problem for sure, and works almost nicely. Thanks for help with the stuff.

There're, like, two noticeable glitches though, one of them is this one issue, for it is a slight regression from the original GE functionality.

I tried to play with -e/-t in December, but didn't think up a nice way. conemu.exe won't accept these switches, while calling conemuc is too late because the echoed cmdline has to be yielded before it starts to run. Maybe the idea was to run an empty terminal (with cmd), then use guimacro to write text, then use guimacro to invoke whatever command should be run for payload?

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 15, 2016

Owner

conemu.exe won't accept these switches, while calling conemuc is too late because the echoed cmdline has to be yielded before it starts to run.

Either I misunderstood what you are complaining of, or you tried -e/-t in some wrong way.
What have you tried exactly, and what was the problem?

Owner

Maximus5 commented Feb 15, 2016

conemu.exe won't accept these switches, while calling conemuc is too late because the echoed cmdline has to be yielded before it starts to run.

Either I misunderstood what you are complaining of, or you tried -e/-t in some wrong way.
What have you tried exactly, and what was the problem?

Maximus5 added a commit to Maximus5/ConEmu that referenced this issue Feb 15, 2016

Maximus5/conemu-inside#3: Write user-defined text to console on startup.
  Commands `echo` and `type` are processed internally by ConEmuC now.
  For example, it's possible to add into the Settings/Environment.

    echo -x "Welcome to ConEmu %ConEmuBuild% terminal^nPress Win-Alt-P to show Settings dialog"

  Alternatively, you may add `echo` or `type` before the command itself,
  when you create new console, or in the Task definition. Example.

    type -utf8 "%ConEmuDir%\Hello.txt" & cmd /k "%ConEmuBaseDir%\CmdInit.cmd"
@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 16, 2016

Collaborator

Tried it on the main conemu.exe — it didn't work, yet were not quite expected to. Just to check.

As with conemuc, how do I make it write smth before the main executable runs under conemu.exe?
There were numerous hypothetical recipes mentioned above, which one is the true one?

The first goal is to have "git pull bla bla bla" text appear in the terminal before "git pull bla bla bla" actually gets running.

UPD: The commit says it about conemuc again, but how do I use it when I run the root conemu.exe?
And the type & approach feels wrong because that type/& is parsed by the command interpreter, which has its own feelings about escaping e.g. ^ chars, as opposed to just starting a child process with such cmdline, and git likes using ^ for some of its revlog expressions.

Collaborator

hypersw commented Feb 16, 2016

Tried it on the main conemu.exe — it didn't work, yet were not quite expected to. Just to check.

As with conemuc, how do I make it write smth before the main executable runs under conemu.exe?
There were numerous hypothetical recipes mentioned above, which one is the true one?

The first goal is to have "git pull bla bla bla" text appear in the terminal before "git pull bla bla bla" actually gets running.

UPD: The commit says it about conemuc again, but how do I use it when I run the root conemu.exe?
And the type & approach feels wrong because that type/& is parsed by the command interpreter, which has its own feelings about escaping e.g. ^ chars, as opposed to just starting a child process with such cmdline, and git likes using ^ for some of its revlog expressions.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

False. Commit says that echo and type are parsed and processed by ConEmu and suggests to use either Settings/Environment or just a Task commands.

There is just one drawback. In current sources, Task's echo commands are executed before echo from Settings/Environment. I consider this is wrong behavior. Task's echo will be executed after echo from Settings.

2016-02-16_10-33-54

2016-02-16_10-35-01

2016-02-16_10-35-59

Owner

Maximus5 commented Feb 16, 2016

False. Commit says that echo and type are parsed and processed by ConEmu and suggests to use either Settings/Environment or just a Task commands.

There is just one drawback. In current sources, Task's echo commands are executed before echo from Settings/Environment. I consider this is wrong behavior. Task's echo will be executed after echo from Settings.

2016-02-16_10-33-54

2016-02-16_10-35-01

2016-02-16_10-35-59

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

Screenshots were taken from debug local build of course

Owner

Maximus5 commented Feb 16, 2016

Screenshots were taken from debug local build of course

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 16, 2016

Collaborator

Great!

But unlike the conventional echo it only takes the text up to the first space, i.e. comspec echo bla bla bla would write bla bla bla, while this one writes bla. Means the arg has to be quoted and escaped, what are the exact escaping rules here? Commandlines would have all sorts of special chars in them. I've applied MSBuild's escaper, but probably it will be slipping.

Collaborator

hypersw commented Feb 16, 2016

Great!

But unlike the conventional echo it only takes the text up to the first space, i.e. comspec echo bla bla bla would write bla bla bla, while this one writes bla. Means the arg has to be quoted and escaped, what are the exact escaping rules here? Commandlines would have all sorts of special chars in them. I've applied MSBuild's escaper, but probably it will be slipping.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

Actually, one cmdline parser is used everywhere in ConEmu. So the rules are the same.

  1. Use double quotes
  2. Use caret to escape: ^t -> tab-char, etc.
  3. (AFAICR) two sequential double quotes are replaced with one: "" -> "
Owner

Maximus5 commented Feb 16, 2016

Actually, one cmdline parser is used everywhere in ConEmu. So the rules are the same.

  1. Use double quotes
  2. Use caret to escape: ^t -> tab-char, etc.
  3. (AFAICR) two sequential double quotes are replaced with one: "" -> "
@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 16, 2016

Collaborator

so ^^ is for ^, right?
and ^"?

Collaborator

hypersw commented Feb 16, 2016

so ^^ is for ^, right?
and ^"?

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 16, 2016

Collaborator

Will have to implement the mangler, otherwise it's no chance git cmdlines will look right.
Where's the parser logic located?

Collaborator

hypersw commented Feb 16, 2016

Will have to implement the mangler, otherwise it's no chance git cmdlines will look right.
Where's the parser logic located?

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

^^ - yes.
^" - no. Can't check ATM

Parser - NextArg
Demangler - DoOutput

Owner

Maximus5 commented Feb 16, 2016

^^ - yes.
^" - no. Can't check ATM

Parser - NextArg
Demangler - DoOutput

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

^^ - yes.
^" - no. Can't check ATM

Parser - NextArg
Demangler - DoOutput

Owner

Maximus5 commented Feb 16, 2016

^^ - yes.
^" - no. Can't check ATM

Parser - NextArg
Demangler - DoOutput

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 16, 2016

Collaborator

Is there a mangler as well there in cpp? Would like to write a test which takes all possible pairs of symbols in 0…127 except for some specials like \0 and makes sure it roundtrips.

Collaborator

hypersw commented Feb 16, 2016

Is there a mangler as well there in cpp? Would like to write a test which takes all possible pairs of symbols in 0…127 except for some specials like \0 and makes sure it roundtrips.

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 16, 2016

Collaborator

Writing a similar thing for command line gave us knowledge that with WinNT command line it is simply not possible to roundtrip an arbitrary string with ", \, ^ in it (i.e. to reliably embed a cmdline). I mean the CRT parser and .NET's which is similar to it. WinAPI parser has some weird rules different from everything else and is not used by anything I know.

Collaborator

hypersw commented Feb 16, 2016

Writing a similar thing for command line gave us knowledge that with WinNT command line it is simply not possible to roundtrip an arbitrary string with ", \, ^ in it (i.e. to reliably embed a cmdline). I mean the CRT parser and .NET's which is similar to it. WinAPI parser has some weird rules different from everything else and is not used by anything I know.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

There is no "mangler" in a code, didn't need it yet.

As for parser... Anyone may check and compare parser from command line, ConEmuC has special -args switch. Example

ConEmuC -args "Test & "" Test"

Can't recall why the rule for double quotes was selected in ConEmu.

Owner

Maximus5 commented Feb 16, 2016

There is no "mangler" in a code, didn't need it yet.

As for parser... Anyone may check and compare parser from command line, ConEmuC has special -args switch. Example

ConEmuC -args "Test & "" Test"

Can't recall why the rule for double quotes was selected in ConEmu.

@Maximus5

This comment has been minimized.

Show comment
Hide comment
@Maximus5

Maximus5 Feb 16, 2016

Owner

http://stackoverflow.com/a/15262019/1405560

But seems like CommandLineToArgW do not conform rules. Thats why internal parser was written.

Owner

Maximus5 commented Feb 16, 2016

http://stackoverflow.com/a/15262019/1405560

But seems like CommandLineToArgW do not conform rules. Thats why internal parser was written.

@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 17, 2016

Collaborator

CommandLineToArgW has its own rules. Which is not a big deal on itself, koz there are no "The Rules" in WinNT, it's up to each cmdline utility of how to parse is input. The issue is that often you want to mangle params for the average utility input (e.g. MSBuild, compilers, cmd, etc), and CommandLineToArgW falls out of the line and behaves differently. Luckily, hardly anyone uses it.

In the native netfx bootstrapper (e.g. this one ) I tried CommandLineToArgW as a very natural idea but soon switched to using MSVS CRT parser from stdargv.c, by taking __argc and __wargv in the ready form.

Collaborator

hypersw commented Feb 17, 2016

CommandLineToArgW has its own rules. Which is not a big deal on itself, koz there are no "The Rules" in WinNT, it's up to each cmdline utility of how to parse is input. The issue is that often you want to mangle params for the average utility input (e.g. MSBuild, compilers, cmd, etc), and CommandLineToArgW falls out of the line and behaves differently. Luckily, hardly anyone uses it.

In the native netfx bootstrapper (e.g. this one ) I tried CommandLineToArgW as a very natural idea but soon switched to using MSVS CRT parser from stdargv.c, by taking __argc and __wargv in the ready form.

hypersw added a commit that referenced this issue Feb 17, 2016

Implements proper mangling of the ECHO text (see discussion in gh-3).…
… Does not work for empty lines, just echo is ignored and echo "" yields two quotes instead of an empty line.

Maximus5 added a commit to Maximus5/ConEmu that referenced this issue Feb 19, 2016

GuiMacro. New function `Write("Text")` writes "Text" to console outpu…
…t (dangerous).

  Use it at you own risk! Calling this function may cause unexpected behavior
  of running console application! That is because function changes console
  contents and cursor position directly, bypassing detouring standard
  ConIn/ConOut processing queue.

  In most cases **safe** functions `Paste`, `Print` and `Keys` are preferable!

  However, with `Write` you may implement some interesting features,
  like printing sort of ‘hints’ in shell prompt:

    Write "\e7\e[90mEcho \"Hello world!\"\e[m\e8"

  Ref: Maximus5/conemu-inside#3

Maximus5 added a commit to Maximus5/ConEmu that referenced this issue Feb 22, 2016

Let `-new_console:c1` stay open silently even on Esc/Enter.
  When all processes in console are finished:
  * ConEmu does not close the console automatically;
  * Confirmation message is not written to console;
  * All keypresses are ignored.

  So, user may either close console via ConEmu interface
  (kill hotkeys or close menu items), or parent process
  (when ConEmu is working in the ‘Inside’ mode) may close
  the console via GuiMacro `Close(0,1)`.

  Ref: Maximus5/conemu-inside#3
@hypersw

This comment has been minimized.

Show comment
Hide comment
@hypersw

hypersw Feb 23, 2016

Collaborator

I've implemented echoing the command and custom greeting text via the environment, and added support for the new Write macro.

Collaborator

hypersw commented Feb 23, 2016

I've implemented echoing the command and custom greeting text via the environment, and added support for the new Write macro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment