Hello all,

Using XPsp3.

A few days ago I tried to redirect some commandline output into a vbscript,
which than should be able to read it using "wscript.stdin.readline".

Examples:
echo hello | myvbscript
myvbscript < data.txt

Alas, all I got was an "invalid handle" error. :-(

The thing is, it works well enough when I explicitily specify wscript like
this

echo hello | wscript.exe myvbscript.vbs
wscript.exe myvbscript.vbs < data.txt

IOW, it likely has something to do with how the OS connects the .VBS
extension to the executable needing to run it, and than launches it.

Question:

Does anyone here know what to change in the registry to enable wscript to
recieve the piped / redirected output ?

Regards,
Rudy Wieser

ps:
I know that I can wrap the vbscript in a few lines of batch script and work
around the problem that way, but thats (work-arounds) not what I'm looking
for.

"R.Wieser" <address@is.invalid> wrote:

> Using XPsp3.
>
> A few days ago I tried to redirect some commandline output into a
> vbscript, which than should be able to read it using
> "wscript.stdin.readline".
>
> Examples:
> echo hello | myvbscript
> myvbscript < data.txt
>
> Alas, all I got was an "invalid handle" error. :-(
>
> The thing is, it works well enough when I explicitily specify wscript
> like this
>
> echo hello | wscript.exe myvbscript.vbs
> wscript.exe myvbscript.vbs < data.txt

In your first example, you specify "myvbscript" instead of
"myvbscript.vbs". Can't have a filetype association (to a handler aka
script interpreter) without an extension on the filename. However, I'm
not sure filetype association works in piped/redirected stdout, but you
could try it. I suspect you must execute a program first to provide
piping or redirection (to have stdin and stdout available by the
program's process). By the time the program (filetype handler) runs,
assuming it does, you've already attempted piping or stdout before the
program has loaded.

echo hello | myvbscript.vbs
myvbscript.vbs < data.txt

Not sure you can pipe or redirect stdin to a file. Has to be to a
program. myvbscript and myscript.vbs are just text files, not
executables. They are text files that something else must interpret.
Looks like you need to pull stdin or push stdout to wscript.exe, a
program, not to a file.

textfile1 | textfile2
Doesn't make sense. No executable to pull stdin or push stdout.

textfile2 < textfile1
Also doesn't make sense. Files don't have stdin or stdout streams.

Somewhere a program must be involved to accept stdin or push stdout.
Files don't push (stdout) or pull (stdin) anything. You read or write
to files, and that's by using some program. There's nothing about a VBS
file. It's just a text file. Need a handler to intrepet them.

As mentioned, you could try specifying the .vbs extension hoping the
filetype handler will pickup the script interpretation, and manage to
intercept stdin or stdout before the interpreter reads the .vbs file.

VanguardLH,

> In your first example, you specify "myvbscript" instead of
> "myvbscript.vbs".

Yes, and that was on purpose.

> Can't have a filetype association (to a handler aka
> script interpreter) without an extension on the filename.

the myvbscript "filename" as in my first example should have a .vbs
extension just like in my second example ? My 'puter seems to disagree
with you. Its able to, in the first example, start the provided vbscript
just fine.

> However, I'm not sure filetype association works in piped/redirected
> stdout, but you could try it.

Ehhh... Whut ?

You're suggesting to me to try what I posted as the problem of this thread ?
Really ?

> I suspect you must execute a program first to provide piping or
> redirection (to have stdin and stdout available by the program's
> process).

Hmmm ... AFAIKS that would create a different problem : the 'program thats
executed first' could abort due to not finding any input on its stdin, or
lose output because its stdout isn't connected yet.

> By the time the program (filetype handler) runs, assuming it does,
> you've already attempted piping or stdout before the program has
> loaded.

:-) That is what a (win32) pipe is for : you write stuff to it, and as long
as nobody is reading on the other end it just gets buffered.

> echo hello | myvbscript.vbs
> myvbscript.vbs < data.txt

But, that was something I hadn't tried yet (as providing the extension
should, in this case, not make any difference). A quick test just now shows
that it doesn't change anything (no workie).

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> VanguardLH,
>
>> In your first example, you specify "myvbscript" instead of
>> "myvbscript.vbs".
>
> Yes, and that was on purpose.
>
>> Can't have a filetype association (to a handler aka
>> script interpreter) without an extension on the filename.
>
> the myvbscript "filename" as in my first example should have a .vbs
> extension just like in my second example ? My 'puter seems to disagree
> with you. Its able to, in the first example, start the provided vbscript
> just fine.

For your first example, you said "all I got was an invalid handle"
error. Your first example errored when you posted, but now it works?

>> However, I'm not sure filetype association works in piped/redirected
>> stdout, but you could try it.
>
> Ehhh... Whut ?
>
> You're suggesting to me to try what I posted as the problem of this thread ?
> Really ?

I suggested NOT specifing just files. Specify a program. Whether
piping or redirection, WHAT are you piping or redirecting? Stdin or
stdout, not the actual file. Something you run has to do the read
(stdin) or do the write (stdout).

Think about it: when you run a console program, its stdout is writing to
the console window. Instead you pipe that program's stdout into a file.
The program is still doing the writing.

>> I suspect you must execute a program first to provide piping or
>> redirection (to have stdin and stdout available by the program's
>> process).
>
> Hmmm ... AFAIKS that would create a different problem : the 'program thats
> executed first' could abort due to not finding any input on its stdin, or
> lose output because its stdout isn't connected yet.

Files don't have stdin or stdout streams. They're just data structures
in a file system, not programs.

>
>> By the time the program (filetype handler) runs, assuming it does,
>> you've already attempted piping or stdout before the program has
>> loaded.
>
> :-) That is what a (win32) pipe is for : you write stuff to it, and as long
> as nobody is reading on the other end it just gets buffered.

But files don't have stdin or stdout streams. Something you run does
the read or write.

>> echo hello | myvbscript.vbs
>> myvbscript.vbs < data.txt
>
> But, that was something I hadn't tried yet (as providing the extension
> should, in this case, not make any difference). A quick test just now shows
> that it doesn't change anything (no workie).

That's why I said that you really need to specify an executable program
that can do stdin (read) and stdout (write). I expected attempting to
get a file to write or read would not work.

stdin, stdout, and stderr are global constant pointers for standard
streams for input, output, and error output. Programs have those
streams. Files do not. You cannot pipe the content of one file into
another file. You can pipe the stdout of one program into the stdin of
another program, or redirect a program's stdout to write into a file.

I know you don't like when something doesn't work they way you expect,
or think it should be, but files don't have stdin or stdout streams.
You already figured out the solution, so why not use it?

VanguardLH,

> For your first example, you said "all I got was an invalid handle"
> error. Your first example errored when you posted, but now it works?

If you *throw the context in which both where said away* than you are right.

Not so much if you keep it in context though.

But I have no wish to /again/ try to fight you to make you understand what
/should/ have been obvious.

Goodby kid.

Regards,
Rudy Wieser

"R.Wieser" <address@is.invalid> wrote:

> VanguardLH,
>
>> For your first example, you said "all I got was an invalid handle"
>> error. Your first example errored when you posted, but now it works?
>
> If you *throw the context in which both where said away* than you are right.
>
> Not so much if you keep it in context though.
>
> But I have no wish to /again/ try to fight you to make you understand what
> /should/ have been obvious.
>
> Goodby kid.
>
> Regards,
> Rudy Wieser

Ah, yes, your moving target to your respondents. Troll ploy.

VanguardLH,

> Ah, yes, your moving target to your respondents. Troll ploy.

Ah yes, the "if I don't get it its your fault" troll ploy.

I think there is *no* way you can tell me the subject/context of either
post. And a hint : it isn't the script.

On Tue, 23 Apr 2024 11:55:36 +0200
"R.Wieser" <address@is.invalid> wrote:

> VanguardLH,
>
> > Ah, yes, your moving target to your respondents. Troll ploy.
>
> Ah yes, the "if I don't get it its your fault" troll ploy.
>
> I think there is *no* way you can tell me the subject/context of either
> post. And a hint : it isn't the script.
>

Are you looking for help or a fight? Just asking, I offer neither.

--
Bah, and indeed Humbug.

On 4/23/2024 12:32 PM, Kerr-Mudd, John wrote:

> Are you looking for help or a fight? Just asking, I offer neither.
>

That's just Rudy's style. When he says, "Screw you, little boy,
you're less than a fly", he means, "I'm not so sure you're right
on that point."

Rudy enjoy's arguing, so he comes up with unsolvable puzzles
and then criticizes the answers. He'll ask things like, "I opened a
program and it instantly closed, yet the other shortcut works fine.
But where did my baloney sandwich go?" Then people make the
mistake of trying to help him sort out faulty shortcuts because,
well, who doesn't love a puzzle? :)

Newyana2 <mayayana@invalid.nospam> wrote:

> On 4/23/2024 12:32 PM, Kerr-Mudd, John wrote:
>
>> Are you looking for help or a fight? Just asking, I offer neither.
>>
>
> That's just Rudy's style. When he says, "Screw you, little boy,
> you're less than a fly", he means, "I'm not so sure you're right
> on that point."
>
> Rudy enjoy's arguing, so he comes up with unsolvable puzzles
> and then criticizes the answers. He'll ask things like, "I opened a
> program and it instantly closed, yet the other shortcut works fine.
> But where did my baloney sandwich go?" Then people make the
> mistake of trying to help him sort out faulty shortcuts because,
> well, who doesn't love a puzzle? :)

He already figured out a workaround, the real-world solution, but wants
the world to work how he wants or expects. To hell with why things work
the way they do. It's gotta be his way.

In this case, he wants files themselves to do reads and writes of other
files. He wants data objects aka files to be programs themselves, so
files can read and write, and can do anything else he wants. He has
watched too many Marvel and Harry Potter movies. Logic interferes with
his obstreperous temperament.

John,

> Are you looking for help or a fight?

I'm looking for the former, but alas, got the latter.

And as I'm absolutily not religious I don't tend to offer the other cheek.

> Just asking,

I've got no problem with that.

> I offer neither.

D*mn - no fight *and* no help ? What is the world coming too ? :-)

Regards,
Rudy Wieser

Newyana2,

> That's just Rudy's style. When he says, "Screw you, little boy,
> you're less than a fly", he means, "I'm not so sure you're right
> on that point."

I can't remember having ever said (or ment) the former, and in regard to
Vanguard I'm past the latter. I tried that several times, but it didn't
work. (Proof on file. Literally)

> Rudy enjoy's arguing, so he comes up with unsolvable puzzles
> and then criticizes the answers.

"unsolvable puzzles" ? You know that for a fact ? In that case I can stop
trying to find a solution to it and put it to rest. You /do/ have something
to back that up ofcourse.

But thank you for the praise - it means that went thru all possibilities in
regard to a solution myself first, and there are none other to check. IOW,
I did/do my own homework first, before trying to involve others. Isn't that
what a good question-poster is supposed to do ?

"come up with" ? Are you seriously trying to make it sound as if I spend
my days manufacturing such "unsolvable puzzles" ? - just because you can't
answer my questions ? Get a reality check please.

But, I'm going to throw you a bone. What I was doing when I ran into the
stated problem is trying to un-double the output of "sort". Like this:
"<in.txt sort | undouble > out.txt". With "out.txt" receiving the unique
lines of "in.txt".

Now if that "undouble" would have been an .EXE or even a .BAT file the input
redirection works. But not for a .VBS file. :-|

"criticizes the answers" ? Are you trying to tell me that I am not allowed
to point out how some of the suggestions would create their own problems ?

And I'm assuming that with those "answers" you're *not* talking about all
those posted work-arounds - where I explicitily mentioned I don't want (or
need) them.

But I will try to remember that, the next time you post an answer, I should
just say "thank you" and leave it at that - no matter the quality of it.
Down side : you won't learn of any mistakes you made. But if that is what
you want ...

> Then people make the mistake of trying to help him sort out faulty
> shortcuts because, well, who doesn't love a puzzle? :)

:-) Seeing that there are industries who thrive on creating jigsaw, sudoku,
crossword, rope and a plethora of other puzzles - lets not forget those
"escape rooms" - I would say there are a /lot/ of them.

Besides all those engeneers and programmers who's job it is to do just that
ofcourse.

But... eh, "faulty shortcuts" ? They are "faulty" how ? As implemented by
MS ? On my machine ? If the former than my queste ends. If the latter I
could use some info about what they are supposed to look like.

Heck, maybe you /do/ have the information I'm looking for. :-)

Regards,
Rudy Wieser

[Disclaimer: I don't know the first thing about VBScript, but have a
brain and am not afraid to use it.]

VanguardLH <V@nguard.lh> wrote:
[...]

> In this case, he wants files themselves to do reads and writes of other
> files. He wants data objects aka files to be programs themselves, so
> files can read and write, and can do anything else he wants. He has
> watched too many Marvel and Harry Potter movies. Logic interferes with
> his obstreperous temperament.

FTR, AFAICT he does *not* "want files themselves to do reads and
writes of other files". (I think) That's your misunderstanding. The
'files' are not "data objects", but a VBScript (myvbscript[.vbs]), i.e.
it *is* a program. That's clear by the fact that the .vbs file *is*
executed.

I don't know how a .vbs file gets executed, but I assume it works like
..exe and .bat files that the command interpreter (cmd.exe) sees that
myvbscript is actually myvbscript.vbs and hence calls wscript.exe to
execute myvbscript.vbs.

Rudy's problem is that he can't imagine that someone interprets his
posts in any other way than he does. If there's another interpretation,
it's the other guy's fault and things go downhill from there.

R.Wieser <address@is.invalid> wrote:
> Newyana2,
[...]
> > Rudy enjoy's arguing, so he comes up with unsolvable puzzles
> > and then criticizes the answers.
>
> "unsolvable puzzles" ? You know that for a fact ? In that case I can stop
> trying to find a solution to it and put it to rest. You /do/ have something
> to back that up ofcourse.

If you think Newyana2 needs to "back up" his "unsolvable puzzles"
statement, you may want to enroll in Logic 101.

I've noted you tend to emit this logical fallacy when you get too
worked up (which is a quite common occurence). There's a lesson in
there.

On 24 Apr 2024 12:46:12 GMT
Frank Slootweg <this@ddress.is.invalid> wrote:

> [Disclaimer: I don't know the first thing about VBScript, but have a
> brain and am not afraid to use it.]
>
> VanguardLH <V@nguard.lh> wrote:
> [...]
>
> > In this case, he wants files themselves to do reads and writes of other
> > files. He wants data objects aka files to be programs themselves, so
> > files can read and write, and can do anything else he wants. He has
> > watched too many Marvel and Harry Potter movies. Logic interferes with
> > his obstreperous temperament.
>
> FTR, AFAICT he does *not* "want files themselves to do reads and
> writes of other files". (I think) That's your misunderstanding. The
> 'files' are not "data objects", but a VBScript (myvbscript[.vbs]), i.e.
> it *is* a program. That's clear by the fact that the .vbs file *is*
> executed.
>
> I don't know how a .vbs file gets executed, but I assume it works like
> .exe and .bat files that the command interpreter (cmd.exe) sees that
> myvbscript is actually myvbscript.vbs and hence calls wscript.exe to
> execute myvbscript.vbs.

You'd be wrong there; 'anyfile.vbs' (or any other 'thing' gets dealt with
by Windows 'associations'); anything ending with '.vbs' would
normally be associated with 'wscript.exe'

'.exe' & '.bat' files (again, normally) get sent to the command interpreter
and are then either executed (if EXE by loading and finding the start
point) or seen as BATCH and interpreted by the command (or should I say
CMD) parser.

>
> Rudy's problem is that he can't imagine that someone interprets his
> posts in any other way than he does. If there's another interpretation,
> it's the other guy's fault and things go downhill from there.

He does seem to want to specify his 'problem' very tightly but then not
accept any workaround suggested. It's pointless trying to help ISTM.

--
Bah, and indeed Humbug.

Frank,

> If you think Newyana2 needs to "back up" his "unsolvable puzzles"
> statement, you may want to enroll in Logic 101.

:-) I did not expect him to prove it. I'm not /that/ daft.

But I think I may expect him to be able to explain /why/ he thinks its
unsolvable. Otherwise his classification isn't worth the ink its written
with.

And pardon me, I've more than once encountered people who use similar claims
just because they either could not grasp the problem, or didn't actually
want to try to solve it. You know, <whining>Its too *hard*</whining>.

> I've noted you tend to emit this logical fallacy when you get
> too worked up (which is a quite common occurence). There's a
> lesson in there.

I disagree. See above.

But, if you can quote something specific we could always discuss it. For
some odd reason I've got very little problem with being proven wrong.

Regards,
Rudy Wieser

John,

> '.exe' & '.bat' files (again, normally) get sent to the command
> interpreter

Even the executables which depend on a GUI ? <whistle> :-)

> He does seem to want to specify his 'problem' very tightly but then not
> accept any workaround suggested.

Lol. I get offered work-arounds when I say *NOT* to want them, and even
though I mention that I already found a working one myself.

As for my "very tightly" ? Yeah, thats /exactly/ because people refuse to
listen. The less (background) information I provide, the less chance they
go off on a tangent.

> It's pointless trying to help ISTM.

Try to answer the question and I wil thank you. Pay me disrespect by keep
pushing what I specifically mentioned I don't want or need and you won't get
my respect either.

Or, to put it more bluntly : As long as someone refuses to work inside the
boundaries I set than their "trying to help" is nothing more than them lying
to themselves and wasting my time.

.... or maybe you want the same treatment as I offered Newyana2 I just say
"thank you" - regardless of what you posted is in any way usable.

Now I think of it, that would likely put a hard stop to all of the
not-answering-the question crap ... I might even try it.

Regards,
Rudy Wieser

Kerr-Mudd, John <admin@127.0.0.1> wrote:
> On 24 Apr 2024 12:46:12 GMT
> Frank Slootweg <this@ddress.is.invalid> wrote:
>
> > [Disclaimer: I don't know the first thing about VBScript, but have a
> > brain and am not afraid to use it.]
> >
> > VanguardLH <V@nguard.lh> wrote:
> > [...]
> >
> > > In this case, he wants files themselves to do reads and writes of other
> > > files. He wants data objects aka files to be programs themselves, so
> > > files can read and write, and can do anything else he wants. He has
> > > watched too many Marvel and Harry Potter movies. Logic interferes with
> > > his obstreperous temperament.
> >
> > FTR, AFAICT he does *not* "want files themselves to do reads and
> > writes of other files". (I think) That's your misunderstanding. The
> > 'files' are not "data objects", but a VBScript (myvbscript[.vbs]), i.e.
> > it *is* a program. That's clear by the fact that the .vbs file *is*
> > executed.
> >
> > I don't know how a .vbs file gets executed, but I assume it works like
> > .exe and .bat files that the command interpreter (cmd.exe) sees that
> > myvbscript is actually myvbscript.vbs and hence calls wscript.exe to
> > execute myvbscript.vbs.
>
> You'd be wrong there; 'anyfile.vbs' (or any other 'thing' gets dealt with
> by Windows 'associations'); anything ending with '.vbs' would
> normally be associated with 'wscript.exe'

Of course, but the point is that in Rudy's first examples, he doesn't
use myvbscript.vbs, but just myvbscript. So *something* must translate
myvbscript to myvbscript.vbs, *before* file associations, i.e.
associating .vbs with wscript.exe, come into play. My guess was/is that
the 'command interpreter' (Rudy doesn't say how he invokes his commands)
does the ttranlation from myvbscript to myvbscript.vbs.

> '.exe' & '.bat' files (again, normally) get sent to the command interpreter
> and are then either executed (if EXE by loading and finding the start
> point) or seen as BATCH and interpreted by the command (or should I say
> CMD) parser.

Again, first something has to translate from <filename> to
<filename>.exe or <filename>.bat. I think (for example) cmd.exe does
that translation.

> > Rudy's problem is that he can't imagine that someone interprets his
> > posts in any other way than he does. If there's another interpretation,
> > it's the other guy's fault and things go downhill from there.
>
> He does seem to want to specify his 'problem' very tightly but then not
> accept any workaround suggested. It's pointless trying to help ISTM.

R.Wieser <address@is.invalid> wrote:
> Frank,
>
> > If you think Newyana2 needs to "back up" his "unsolvable puzzles"
> > statement, you may want to enroll in Logic 101.
>
> :-) I did not expect him to prove it. I'm not /that/ daft.

<whoosh!>

I think somebody complained about people not reading what was written,
but going off on a tangent. Who was that again!?

> But I think I may expect him to be able to explain /why/ he thinks its
> unsolvable. Otherwise his classification isn't worth the ink its written
> with.

Sorry, same logical fallacy.

> And pardon me, I've more than once encountered people who use similar claims
> just because they either could not grasp the problem, or didn't actually
> want to try to solve it. You know, <whining>Its too *hard*</whining>.

I vaguely remember mentioning it's always the other guy's fault.
>
> > I've noted you tend to emit this logical fallacy when you get
> > too worked up (which is a quite common occurence). There's a
> > lesson in there.
>
> I disagree. See above.

Another locigal fallacy.

> But, if you can quote something specific we could always discuss it. For
> some odd reason I've got very little problem with being proven wrong.

Yep, and I've a 300-metre steel tower in Paris for sale, real cheap,
honest!

Frank,

> My guess was/is that the 'command interpreter' (Rudy doesn't say
> how he invokes his commands)

I didn't ?

[quote first post]
I tried to redirect some commandline output into a vbscript
[/quote]

Besides that, the "echo hello | ..." and "... < data.txt" should have been
dead give-aways.

Regards,
Rudy Wieser

Frank,

> <whoosh!>
>
> I think somebody complained about people not reading what was
> written, but going off on a tangent.

You *might* want to explain that to me.

> Sorry, same logical fallacy.

You are ofcourse able to explain /why/ you think so.

.... Or is that another "logical fallacy" to you ?

> I vaguely remember mentioning it's always the other guy's fault.

I see you complain a lot, but not bringing a sliver of information forward
to my stated problem.

But, feel free how *your* whining and not even /trying/ to respond to (let
alone answer) the question is actually helpfull to me.

> Another locigal fallacy.

Ofcourse, just keep using the same big words, but not once support them by
anything. Makes you sound like someone reely intulligant.

Goodbye Frank. And "thank you"

Regards,
Rudy Wieser

Frank Slootweg <this@ddress.is.invalid> wrote:

> FTR, AFAICT he does *not* "want files themselves to do reads and
> writes of other files". (I think) That's your misunderstanding. The
> 'files' are not "data objects", but a VBScript (myvbscript[.vbs]), i.e.
> it *is* a program. That's clear by the fact that the .vbs file *is*
> executed.

VBScript is an interpreted language, not a compiled one.

..vbs are text files. That they contain scripts is only useful when they
are read by an interpreter. .vbs files are not executable. They are
read by an interpreter that does the code execution. You can compile
..vbs files, like after porting to VB or VB.NET and then *compiling* the
script) into .exe files, but then they are .exe files, not .vbs text
files describing a script.

He wants to pipe or redirect files into files, like:

textfile1 | textfile2
textfile2 < textfile1

He discovered the solution was to specify the .vbs extension on the
filename to get that handler to read the text file to run the script.

> I don't know how a .vbs file gets executed, but I assume it works like
> .exe and .bat files that the command interpreter (cmd.exe) sees that
> myvbscript is actually myvbscript.vbs and hence calls wscript.exe to
> execute myvbscript.vbs.

Batch (.bat) files are just text files, too. They are not executable.
They must get interpreted by cmd.exe. Likewise, the filetype
association on .bat has the text file read into command shell to do the
interpretation of the script.

Personally I wouldn't rely on filetype association hoping the handler
gets loaded at the right time to load the text file to run the script
and generate the stdin, stdout, and stderr streams.

R.Wieser <address@is.invalid> wrote:
> Frank,
>
> > My guess was/is that the 'command interpreter' (Rudy doesn't say
> > how he invokes his commands)
>
> I didn't ?
>
> [quote first post]
> I tried to redirect some commandline output into a vbscript
> [/quote]
>
> Besides that, the "echo hello | ..." and "... < data.txt" should have been
> dead give-aways.

As you didn't specifically say you invoked from cmd.exe, I said
'command interpreter', i.e. the general term. That's all.

Your accusive and defensive response just confirms what others and I
have been saying about your style of communication ("Rudy's problem is
that he can't imagine that someone interprets his posts in any other way
than he does.").

FTR, in that subthread (the context of which you fully snipped :-(), I
was actually supporting your 'side' in the context of VanguardLH's
comments. But that was whooshed over, because you had to find fault
*somewhere*! :-(

EOT.

VanguardLH <V@nguard.lh> wrote:
> Frank Slootweg <this@ddress.is.invalid> wrote:
>
> > FTR, AFAICT he does *not* "want files themselves to do reads and
> > writes of other files". (I think) That's your misunderstanding. The
> > 'files' are not "data objects", but a VBScript (myvbscript[.vbs]), i.e.
> > it *is* a program. That's clear by the fact that the .vbs file *is*
> > executed.

[Series of 'Duh!'s and misinterpretations deleted.]

See my response to John. It's not about filetype association, etc.,
but about what translates <filename> to <filename>.vbs *before* filetype
association takes places, i.e. similar to (*not* 'the same as') how
<filename> gets translated to <filename>.bat.

BTW.:

> He wants to pipe or redirect files into files, like:
>
> textfile1 | textfile2
> textfile2 < textfile1
>
> He discovered the solution was to specify the .vbs extension on the
> filename to get that handler to read the text file to run the script.

Nope, he 'discovered' no such thing. He specified the .vbs extension
*and* he added wscript.exe to interpret the .vbs file.

One of the many problems resulting from his snipping of context.

On 24 Apr 2024 17:41:43 GMT
Frank Slootweg <this@ddress.is.invalid> wrote:

[]

>
> Yep, and I've a 300-metre steel tower in Paris for sale, real cheap,
> honest!

Don't buy it! the Eiffel tower is made of wrought iron.

--
Bah, and indeed Humbug.