XPost: alt.windows7.general   
   From: V@nguard.LH   
      
   "R.Wieser"  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?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)