popen - Githubissues

carlos-montiers commented 5 years ago

The popen feature currently is implemented using a @@ syntax. This unlikely because for example if you enter a set /p command something like: @@calc it will execute the calc command. For solve this the popen extension should be implemented as something related to the curly brace expansion. With that the popen extension will work only when be typed directly in the batch script code.

DaveBenham commented 4 years ago

I agree that the current syntax of set var=@@someCommand is problematic because it does not allow defining a value that begins with literal @@.

If curly brace expansion is implemented, then I agree that would be a good place to implement popen. But in lieu of that, how about set var @= someCommand instead.

adoxa commented 4 years ago

It loses the ability to embed %@@command% within another command, though, which I'll admit might not be that big a deal, but still something I'd like to keep. How about set var `= command and %`command%? (Backtick being the Unix-style shell operator for similar expansion.) Hm, but that has the problem with set /p, as does any other such expansion. Might see if I can detect set /p and disable the expansion.

DaveBenham commented 4 years ago

It loses the ability to embed %@@command% within another command, though, which I'll admit might not be that big a deal, but still something I'd like to keep.

I'm having trouble understanding how that works. Can you give a short example showing what the final result would be?

How about set var `= command and %`command%?

I don't see how that is any different than set var @= command and %@@command% (or if you adopt #39, then %=@@command%)

adoxa commented 4 years ago

I'm sure it's useful, but I can't think of a practical example, so I'll settle for the lame echo Hello %@@whoami%.

As I said, backtick is already used in the UNIX world (echo Hello `whoami`), that's all.

DaveBenham commented 4 years ago

Thanks, now I understand what you mean. I thought you meant you wanted to embed @@command within another @@command, which doesn't make sense. But embedding @@command within percent or delayed expansion does make sense.

Even if you implement !@@command!, I can still see at least two reasons why set var @= command would still be useful

Easier to append arguments to the command - everything after @= would be part of the command. Providing all required arguments within percent or delayed expansion could become awkward.
%@@command% and !@@command! would both be limited to ~8191 characters. I think you don't have that limit with @= as long as you store the result in a heap variable. Though I'm not sure what you can do with the long value once you have captured it. Hopefully you could augment FOR /F to read from a heap variable directly without first expanding within the parser, so then you could process a large value as long as no line exceeds 8191. Perhaps other extensions could process large values.

adoxa commented 4 years ago

!@@command! is already implemented. Currently the variable is restricted to 32Ki (the maximum size of an environment variable), but there's no reason a heap variable needs that limit. Substitution is restricted to 8Ki (the size of the buffer) and there's no practical way around that. There are plans for FOR /F to process variables directly, but nothing decided yet.

carlos-montiers commented 4 years ago

This was solved with the := notation. Now only works when you use that notation. editor.cmd

eb load
echo Press ctrl+c for end
set text := @@more
set text

carlos-montiers / enhancedbatch

popen #7