Today was another development nightmare day, everything seems to be cloaked in wrong events. Me under pressure and Winbloat — call it Micro$oft Windows — fails everywhere I need it working.
In the company where I work we use some tools to validate the source that is given to the clients and coding IDEs to work around languages such as Java and .RETARD — call it .NET if you want — including Eclipse and Visual Studio. Also, there are some proprietary validation tools to use with proprietary structured text file formats out of known standards.
Events related to eclipse were things like loosing library references — jar files — and slow project compiling tasks and non-writable files after file locking actions given by the operating system — do you know I work with Micro$oft Wintendo? — and then a reboot is the only solution — I know the unlocker program, but I don’t have it installed and also I prefer a solution given from the product manufacturer. Well, the project is huge, a lot of lines of code and classes to compile and really can’t imagine a .RETARD project with similar to this, I think that is possible to get a half day compiling a .RETARD project with all those lines of code.
Looking at the proprietary validation tool, from the Yoyodine company, I get "everything is working" messages. Since I know a little about Perl and I’ve prototyped some of my work under Perl — such as acl-user-tools, a small C language project to manage users around a web hosting environment — and, just for fun, some Irssi scripts, such as Irssi Exp. I use terminal based IRC clients, since while I’m working under FreeBSD-CURRENT I need lightweight software.
Here the point turns black. Since Micro$soft Wintendo has an association registry between the file extensions and the script interpreter, I was completely wrong about calling scripts directly from the command line without giving the path to the interpreter under the non-user-friendly Wintendo Command Interpreter known as cmd.exe.
C:somewhereinthedisk > yoyodine-validator.pl < file-to-validate.txt There isn't problems in the given file
Everything is OK and I’ve sent the software parts to the company client. The response was clear "have you validated the software?". Nothing working in the Wintendo Non-Operating System, and I get this response, since I have lunched in 20 minutes to get software validated and working at time for two weeks and two days, I was hating the non-operating system for a while with the fixed idea of kicking off my workstation.
Looking at the file association registry, the way by I was running the yoyodine-validator.pl isn’t wrong for someone who knows about scripting languages such as Perl. Under *NIX operating systems — call it *BSD or Linux — scripting languages runs using magic strings and file permissions. The magic string isn’t so different from the form "#!/path/to/interpreter" at the beginning of the script and the file permissions are execution permissions to the user that is running the script. Micro$oft Wintendo have a different way to make a script runnable.
I have associated the perl extension and the running statement is:
Since a perl script can have many arguments, the first thing wrong in the calling statement is number of arguments, passing just the first argument — anyone knows if the cmd.exe command line interpreter is well documented anywhere? — and the rest of the argument aren’t present in the calling statement.
If you remember the script was called using I/O redirection, inherited from *NIX systems, and these arguments aren’t passed directly to the interpreter, instead are handled by command interpreter. Since the registry calls the native Wintendo shell — known as Wintendo Explorer — it ignores the input redirection given from the command line. The result, is an input stream completely loosed. Then I think "wintendo command line shell cmd.exe and windows shell explorer.exe aren’t integrated" since you can not pass an input stream from the command line to the program launched from the Wintendo shell. Another non-documented and buggy behavior of this non-operating system.
The solution to work with similar tasks is calling the programs directly from the command line, overriding the cmd.exe pass-through-the-real-shell explorer.exe calling statements. Then we can’t emulate the *NIX magic strings and file permissions to get a script working as a native command. Somewhere I’ve seen a magic string to work with script interpreters, but "where is documented?" and "does the system comes with the proper documentation to work on these kind of tasks?".
C:pathtoanywhere > C:pathtoperl.exe yoyodine-script.pl < to-validate.txt
A single line of code changes the behavior of a script program completely. If you ask me, Micro$oft Wintendo is thinked to work with games, word processors and spreadsheets. Wasn’t thinked as *NIX as we see in "Program design in the UNIX© environment" and do not have in any manner a consideration on integration between streams connectivity. If you want to integrate any component of the non-operating system, you must write an Active X object or write similar things — a high-cost implementation for a small task — then I think that Micro$oft Wintendo isn’t an harmoniously developed operating system.
The possible reason about this behavior it’s that cmd.exe is using the ShellExecute system call, instead of using a proper way to handle I/O redirection or piping functions. If I’m true, you can’t expect the right behavior on scripts if your trying to run them under cmd.exe by using registry associations on the scripts files. Then, you must research about possible magic strings in batch commands and use the script under these terms. Meanwhile isn’t a well documented way to use language interpreters under windows, you will not be able to run scripts directly…
Entries 