Can't Pipe Input to set /p

[KMyers1]

The set command with the /p option will accept the contents of a
redirected file as its input, such as:

echo test1>myfile.txt
set /p myvar=<myfile.txt

However, using the set command with the /p option and piping input to
the command does *NOT* seem to work, such as:

echo test2|set /p myvar=

How can input redirection work when using a pipe fails? Piping and
indirection are supposed to be transparent and equivalent to any
program that accepts console input!!!???

Kevin M.

 

[Jon]

If that's a real world example, then just use this command instead

set myvar=test2

Otherwise it's a very roundabout way of setting the value of a variable.

--
Jon

It's not computer literacy that we should be working on, but sort of
human-literacy. Computers have to become human-literate. ~Nicholas P.
Negroponte

 

[KMyers1]

If that's a real world example, then just use this command instead

Well heck Jon, of course it's not a real world example!!! Geez...

In the real world, I am trying to capture the output of arbitrary
commands in environment variables. Certainly not something as simple
as ECHOing constant text.

The examples shown were strictly for example purposes to show that
there appears to be some kind of BUG in either piping or the set /p
command under Win 2K and XP.

In answer to your next question, YES, I do know that a variant of the
FOR command can be used for this purpose. But using set /p would be a
lot simpler, and more importantly it SHOULD work, if there wasn't a bug
somewhere. There should be absolutely no difference in the results of
the two examples that I provided (other than the values test1 vs.
test2). The fact that there is a much more significant difference
shows that something isn't working right, and should be investigated by
Microsoft.

s/KAM

 

[Jon]

Another option would be to use a higher level language like vbscript
(extension vbs) to capture the output of your 'arbitrary commands'.
eg


Dim WshShell, oExec, outputlines
Set WshShell = CreateObject("WScript.Shell")

Set oExec = WshShell.Exec("c:\somefile.bat")
outputlines=oExec.stdout.ReadAll
wscript.echo outputlines


where somefile.bat contains the particular command(s) for which you want to
capture the output.

Vbscript would also offer simple, & more versatile [ and perhaps also less
buggy ] methods for making use of the results, than the rather
antiquated command line.

 

[KMyers1]

Hi Jon,

I'm sure that you are trying to be helpful, but I'm already aware of
possible "solutions" via the "for" statement, 3rd party command line
tools, and switching to other languages. I don't need yet another
"solution".

I just want Microsoft to fix this bug in Windows so that piping to set
/p works as documented, i.e. the same way that piping works with every
other command that works with console input redirection, and the same
way that it works with similar third party tools (e.g. xset).

If you don't work for Microsoft, then I'd appreciate it if you wouldn't
follow up with another reply in this thread. On the other hand, if you
do work for Microsoft, then I'd appreciate it if you could either add
this bug to your list of things that need to be fixed, or explain why
you are so resistant to fixing this so that it works like it ought to.
Compatibility isn't an issue, since right now piping input to set /p
doesn't do anything even vaguely useful.

s/KAM

 

[Admiral Q]

Hi Jon,

I'm sure that you are trying to be helpful, but I'm already aware of
possible "solutions" via the "for" statement, 3rd party command line
tools, and switching to other languages. I don't need yet another
"solution".

I just want Microsoft to fix this bug in Windows so that piping to set
/p works as documented, i.e. the same way that piping works with every
other command that works with console input redirection, and the same
way that it works with similar third party tools (e.g. xset).

If you don't work for Microsoft, then I'd appreciate it if you wouldn't
follow up with another reply in this thread. On the other hand, if you
do work for Microsoft, then I'd appreciate it if you could either add
this bug to your list of things that need to be fixed, or explain why
you are so resistant to fixing this so that it works like it ought to.
Compatibility isn't an issue, since right now piping input to set /p
doesn't do anything even vaguely useful.

s/KAM

FYI - these are peer-to-peer newsgroups, even though these newsgroups
are hosted on microsoft servers, the microsoft employees seldom answer
questions (although occasionaly they do), they mostly just keep a watch on
them. If you wish to report a bug, then there are channels on each of the
products home pages at microsoft to follow in order to report them and that
is where you need to report your bug.
Anyway I tested the scenario you spoke, on WinXP SP2 32-bit, and it
works as advertised as long as it is run under a "cmd.exe" window, but fails
miserably while run under a "command.com" - which may explain your issue.
Command.com is supplied for backwards compatility for programs that look for
command.exe, if programing a cmd, bat or other script type process on an NT
OS, we should definitely be using cmd.exe.

 

[Jon]

Hi Jon,

I'm sure that you are trying to be helpful, but I'm already aware of
possible "solutions" via the "for" statement, 3rd party command line
tools, and switching to other languages. I don't need yet another
"solution".

I just want Microsoft to fix this bug in Windows so that piping to set
/p works as documented, i.e. the same way that piping works with every
other command that works with console input redirection, and the same
way that it works with similar third party tools (e.g. xset).

If you don't work for Microsoft, then I'd appreciate it if you wouldn't
follow up with another reply in this thread. On the other hand, if you
do work for Microsoft, then I'd appreciate it if you could either add
this bug to your list of things that need to be fixed, or explain why
you are so resistant to fixing this so that it works like it ought to.
Compatibility isn't an issue, since right now piping input to set /p
doesn't do anything even vaguely useful.

s/KAM

A bit like expecting the manufacturers of the latest plasma tvs to
devote their energies to fixing an old black and white set, bought years
previously - but you've made your point, if a little rudely

Jon

 

[KMyers1]

Admiral Q (No-Spam-Man Can-the-Spam) wrote:

FYI - these are peer-to-peer newsgroups, even though these newsgroups
are hosted on microsoft servers, the microsoft employees seldom answer
questions (although occasionaly they do), they mostly just keep a watch on
them.

Right. I just didn't want Jon's replies to my posts to make it seem as
if Jon had adequately addressed the issue that I raised. I wanted it
to remain obvious to the Microsoft lurkers that a problem remains that
needs to be corrected.

If you wish to report a bug, then there are channels on each of the
products home pages at microsoft to follow in order to report them and that
is where you need to report your bug.

In the past I have had trouble locating and using these channels.
Perhaps they have been improved and made more usable since I last
tried. Maybe I should try again...

Anyway I tested the scenario you spoke, on WinXP SP2 32-bit, and it
works as advertised as long as it is run under a "cmd.exe" window, but fails
miserably while run under a "command.com" - which may explain your issue.
Command.com is supplied for backwards compatility for programs that look for
command.exe, if programing a cmd, bat or other script type process on an NT
OS, we should definitely be using cmd.exe.

That is *very* strange. I am also running under WinXP SP2 32 bit,
cmd.exe. Are you quite certain that you tried the specific examples
that I provided? Try this:

echo testing|set /p myvar=
set myvar

On my system this reports "Environment variable myvar not defined".
What does it do on yours?
I specifically confirmed yet again that I am *not* accidentally running
command.exe.

s/KAM

 

[KMyers1]

Jon wrote:

A bit like expecting the manufacturers of the latest plasma tvs to
devote their energies to fixing an old black and white set, bought years
previously - but you've made your point, if a little rudely

Hi Jon,

No, it's not the same, because the set command is still a fully
documented and supported part of the OS. It has not been deprecated in
any manner.

I apologize for the seeming rudeness; it was not my intention to be so.
As mentioned previously, I know and appreciate that you were trying to
be helpful. I was just worried that if I left your reponse as the
final statements in this thread, that Microsoft lurkers might get the
impression that my needs were addressed by the alternative solutions
you suggested, when what I really want is simply for this (apparent)
bug to be corrected.

It seems strange that Admiral reports my example works correctly on his
system. If that is confirmed, then I will have to try to track down
some key difference between his machine and mine.

s/KAM

 

[KMyers1]

Further research reveals the true nature of the problem...

It turns out that set /p does in fact receive as input any output that
is piped from a preceding command, and does set the specified
environment variable to the expected value. HOWEVER, it also turns out
that a NEW instance of cmd.exe appears to be spawned for each new
command that is executed as the output side of a pipe, including set /p
in this case.

SO, the newly populated environment variable is ONLY created in this
NEW instance of cmd.exe. Therefore it disappears when the new instance
of cmd.exe goes away after the set /p command has finished executing.
Thus population of the desired environment variable NEVER OCCURS in the
ORIGINAL (pre-pipe) INSTANCE of cmd.exe.

SO, all of that begs the following questions:

1) Isn't it a BUG for a new instance of cmd.exe to be created for
processing the output side of a pipe, IFF the output side of the pipe
is an INTERNAL command?

2) Can anyone think of a way to avoid this problem, such that the
desired environment variable is populated in the ORIGINAL instance of
cmd.exe (the one that is executing before the pipe is encountered)?

Thanks,
Kevin M.