This is in response to http://portablefreeware.com/forums/view ... hp?p=15194

In another forum, someone was asking about nircmd, and its exclusion from the database. The reason for exclusion is that most all console, or "DOS" apps (as use older folk knew of them) apps can be considered portable.

I rejected Portabilizer, and some other means of making an interface for command line apps due to one flaw: command line parameters that are variable don't seem to be included. PStart suggests command line parameters, but I have not been able to get them to work.


My own workaround: BatToExe v1.4 (http://www.f2ko.de), some of Horst Schaeffer's 32-bit batch apps with prompts (http://home.mnet-online.de/horst.muc/win.htm), and the command line app in question.

I create a .bat file, using the Schaeffer utilities to ask the prompts. I then put the .bat file with the used utilities into one directory, and compile with BatToExe in Ghost Application mode (keeps the console from appearing!)

Note: to make the program stealth, the app in question must be stealth, and the batch file must clean up its files after itself, as the first thing it does is extract the Schaeffer utilites and the app program(s).

"Compiled" batches have no bug-free way to store relative paths.
Therefore I recommend not to use it. Batches themselves are better.

_________________

Looking into this: what about environment variables or temporary text files?

Wow, an old thing.
I don't know what do you mean by "environment variables or temporary text files". To do relative paths right, you'd have to first know the directory in which your batch is placed and with most compiled batches you have no way to get it, %cd% can be anything and %~dp0 is some file in temp.

Anyway, I remember seeing a "compiler" that hacked the issue, after a quick look it looked OK.
It took your batch and built another from it; one that did a 'shift' and run your code.
The exe launcher would extract the script to text (like all batch 'compilers' do) and execute from there, but providing own exe path (or something like that) as the first parameter and passing parameters that it got after it.
This way, the user batch had exe name as %0 and all other parameters after it, about the same as it would get by not being "compiled" in the first place, so you could use %~dp0 and have it working. Still it didn't work correctly with some fun stuff (like self-modifying scripts), but for 99% of users should be good enough.

So if you really want to "compile", I recommend using that "compiler".
You may ask how is it called...I don't know, it was a brief look years ago. Others might be able to help. I think sb. from here showed me the program.

_________________

I think you will find that AutoHotkey scripts can do anything a batch file can do, and far more. The syntax is very similar and easy to learn, the only drawback is that a compiled AHk script will have a much larger file size than a batch file. A minimum of about 400kb.

_________________
"My dear Mr Gyrth, I am never more serious than when I am joking."
~Albert Campion
------------------------------------------------------------------------
Website | Demo scripts | Blog | External contact

I think you answered it anyway, m^2. Thanks for the feedback, fellas, much appreciated...