I understand the GUI vs Automation conflict -- bugs me too at times. However,
the world has left command line programs in the grave yard, unless you
like Linux/Unix shell programming, eg
rcp ./*.doc remoteHost:~myid/archive/
which copies local .doc files to another system.
I'm not sure about that... batch scripts are very common and many common GUI apps accept command line triggers and switches.
It's not even really dos anymore as most of these programs only work within CMD and wouldn't run in a pure dos environment. It's just command line interaction.
And the fact that this mode is thriving on linux is indicative of it's general utility... therefore I don't see it dying on any future OS (Windows, linux, OSX).
Beyond that, a real virtue of command line interaction is not only automation but getting different programs to talk to each other. Once a given program starts not only accepting input via command line but outputting something as well... it becomes very easy to integrate various programs into a unified system. Trying to make that happen in GUI is difficult, unreliable, relatively slow, and tends to make multi tasking difficult as such things tend to monopolize the UI (as opposed to a single command window that you can minimize and not worry about screwing up other things).
That valuable... This is one of the major reasons I try to use programs that at least accept command line interaction. For example, I use a credit card gateway program that has a GUI and is typically interacted with the mouse. However, going through the process of importing billing information into it every day manually, and then executing the billing operation is a pain in the ***. So instead I have a batch script that tells my windows database to output a comma separated text file with the relevant information, wait for that to be done, execute the billing gateway, import the info into the billing queue, charge it, delete the comma separated file, terminate the credit card gateway upon completion, and then create a system beep to let me know it's done.
The whole process takes something like 20 seconds and only ties up the database program and credit gateway. No crazy windows popping up... no mouse cursor jumping all over the place, no having to worry about touching the keyboard while it runs. THAT is multitasking.
Now sure, I could gave gotten a database or credit gateway that would seamlessly integrate with each other. But no such system exists that works as well as this system does (excluding some proprietary custom programmed system that I cannot buy and could not afford to have programmed). I would have to accept an inferior database, inferior credit software, or an inferior bank (rates) to make that happen.
So I said screw that... and wrote a two page batch file that handles the integration, works 100 percent of the time, and seriously makes blue birds appear out of no where and sing on my shoulders.
it makes the world a better place...
"Mount" is tightly integrated into the OS, and you're not going see some package
begin offered at any price with the description given.
Actions between systems is the realm of Client/Server software and you just don't
get that in "DOS".
Then why can I mount files as CDROM disks (Daemon Tools)... or FTP sites as networked drives (Net Drive)?
All it has to do is emulate a fixed device driver and then handle the protocol shift between the network share and the mount point.
Ok, that's not easy but there are lots of programs out there that do more complicated protocol shifts.
Like I said originally, DOS was brain dead in ignoring the issue of networked files and
that lead to many cross-linked files -- oh yea -- let's all go back to DOS (teasingly).
I like programs that don't assume they're smarter then I am... Yes, DOS is stupid but I'm not and I'm willing to do the thinking for it. Windows is simply denying me the option to even try.
I find that annoying. Doubtless the first attempt will lead to pain and tears. But the second might work...
You're between a rock and a hard spot on this one and gently suggest you save time and effort and look for other 'available' solutions.
I think you're right. It will probably save time to try to bypass the whole issue by using a program that is specifically compatible.
however, i might just use a program that is too stupid to know the difference... and avoid problems by doing the thinking for the program... instead of assuming it knows what it's doing.