I wanted one more level of customization in CommandPromptPortable -- Filename and Path completion. (It defaults to "off" on many machines.) So I decided to modify the existing CommandPromptPortable to provide that.
I tried to follow the version 1 source as much as possible.
The way it works is: it reads the two settings from an ini file, updates the registry before executing cmd.exe, then puts the regisry back the way it was. When it first runs, if there is no ini file, it reads the current settings from the host machine and stores them in the ini file.
I'm not sure what the version numbering around here is like. It's not a huge change.
I am not real confident about how this works on win95 and its ilk, or NT4. Anyone able to try it out?
Feel free to make lots of suggestions.
[download site withdrawn; if you want to see a copy, let me know]
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
or John might blow you down.
--
As all of ya should know Micro$oft is the Evil Empire, and Windows (a.k.a. Winblows or Windoze) is their greatest general, so please make a difference and install Linux or FreeBSD on yer Windows comp.
(as you would have seen if you had tried it
) and besides, it is offered to him in case he wants to use it.
Maybe we should think about a standard compiler switch that creates unofficial or beta versions with different visual identity and trademarked phrases; that way we could create testing or mod versions for John's consideration that are obviously not "official", but wouldn't require a whole lot of testing to put into "official" format.
Or does something like that exist already and I've just missed it?
MC
but I like the idea.
“I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.” - Richard P. Feynman
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
I was thinking of modding the Command Prompt Portable launcher to check the OS, and if it's a linux machine, it would launch the Terminal. (i just wanted to figure out what the simplest way to launch the terminal was, because each linux distro usually has a different program for it).
______________________
Signature...What Signature?
With FreeBASIC you can make it possible. Since I can make launchers in windows it is possible to cross compile to linux because FreeBASIC has a linux version too
-----------------------------
"I don't fear Computers. I fear the lack of them" Isaac Asimov
My Personal Blog in the making at a new address thibeaz.com
your friendly neighbourhood moderator Zach Thibeau
Is it not possible with NSIS as well?
______________________
Signature...What Signature?
I don't think so as nsis is really compiled to fit the specifications of a pc running Windows and not linux. Unless some modifies NSIS to run linux executables, It's really impossible afaik
-----------------------------
"I don't fear Computers. I fear the lack of them" Isaac Asimov
My Personal Blog in the making at a new address thibeaz.com
your friendly neighbourhood moderator Zach Thibeau
I didn't think about Linux executables.
_______________________________________________
Wow, I just noticed I still had a signature, that's enough of that.
Think about the complexity you'd have to add either to each launcher for that, which is a lot, or recompile NSIS, which we certainly aren't doing. To do it yourself, just replace the splash screen. Done. Simple.
----
Ryan McCue.
Blog.
So all that Airbus-delay trouble over here in Europe is because of YOU!
Simeon.
"If you're not part of the solution, you're part of the precipitate."
1. NSIS is for Windows binary installers only. It can compile on Linux but there is no NSIS for *nix.
2. Binaries running within Wine can not launch Linux apps, so it can't bring up a terminal window.
3. Is it really necessary to make this launcher a lot more complicated (and probably have additional support requests about how to set the auto-completion key)? Auto-completion is on by default on all Windows XP and up installations and most people don't disable it. And, even if it's not, you can type
cmd /fat the command prompt to enable it (or add it right into your Command Prompt Portable's batch file). The only thing this addition would gain is the ability to use command prompt completion on Windows 2000 (where it is supported by off by default). It won't affect 95/98/Me/NT since they don't support command completion.Sometimes, the impossible can become possible, if you're awesome!
It would have been fun if it could launch the terminal.
_______________________________________________
Wow, I just noticed I still had a signature, that's enough of that.
" "
--
As all of ya should know Micro$oft is the Evil Empire, and Windows (a.k.a. Winblows or Windoze) is their greatest general, so please make a difference and install Linux or FreeBSD on yer Windows comp.
On my Windows XP machine, the help message for cmd.exe says "File and Directory name completion is NOT enabled by default." Maybe it is lying?
It also says that the default when you just turn it on with /f:on is ctrl-F and ctrl-D. My fingers prefer Tab, because that's what bash is set for. The only way to set that is in the registry, according to the Help message. (TweakUI can do it, but I don't really want to go there...)
I was tempted while messing with the registry to keep the setting for Quick Edit too, but that can be set in the properties dialog.
So you see, I thought I was adding something that was not possible any other way -- having a preference for completion character. Setting the character to something other than space also turns it on, so that is a side benefit...
MC
It's on by default on Windows XP installs. I just checked my base install of Windows XP that I use for testing (just Win XP installed and then fully updated... no additional apps or other changes). In a default commandline instance, completion is on and uses the TAB character.
Oddly
cmd /fjust seems to turn it on and use CTRL-F even if it's already on and using TAB.Sometimes, the impossible can become possible, if you're awesome!
Perhaps older XP installations had it off by default and SP1 or SP2 has it on by default. My home machine had it off, but I turned it on, and it uses Tab.
Vintage!
As far as support is concerned, we're talking about a Command prompt here. If they can use the command prompt, they shouldn't need much support...
There are two settings in an ini file. There are examples of the most common variations for people to copy.
The initial setup is such that it copies whatever is on the first machine, theoretically the home machine. If the person has figured out how to set up that preference (TweakUI or a registry setting), it will be copied for her.
So: support can consist of "unplug your USB drive; set up the completion characters the way you like them and test; insert the USB drive; delete the commandprompt.ini file in the .\data directory; run CommandPromptPortable to copy your preferences." If they don't have a preference set up on their home machine, then they shouldn't be worrying about taking it with them on the road.
MC
I've done some snooping around, and it appears that the CompletionChar is set to tab on XP and later machines, with PathCompletionChar not set. My changes didn't anticipate that PathCompletionChar would not be set, so I'll need to fix it so it puts things back the way it found them.
I guess the question would be, does John H. want me to work on it more, or should I just take it down and go on to another project?
It currently is good enough for me, but before it gets released it needs a bit more work.
No hard feelings if John doesn't want it changed. I've got what I need, and learned a lot about NSIS in the process.
MC
To my knowledge, you're the only one that ever even asked about it, so I don't know if anyone else would use the feature. I'd say hang onto your code and if a few people ask, we'll put it through its paces and add it or a variant of it in.
Sometimes, the impossible can become possible, if you're awesome!
Maybe off thread but I'll ask anyway.
I know that this is simply a wrapper around the existing cmd.exe app.
On my current site, running of this is disallowed via a group policy.
I know that the existing M$ cmd.exe could not be distributed as it is not open source. Does such a thing as an open source command prompt REPLACEMENT exist?
Or am I just being stupid?
Definitely off-thread. And, no, not that I know of. Everything I've seen is just a wrapper for it (including Console which is mentioned in another thread).
Sometimes, the impossible can become possible, if you're awesome!
Funny, I was thinking I might look at one of the sh programs (native win32, not cygwin) to see what they might be like as an alternative. I think I recall that some depend on CMD.EXE somehow, but maybe others don't.
I think I recall hearing of some geeks using Perl as their shell. Or maybe it was emacs. Have you thought of trying that?
If the computer is locked down to the extent of prohibiting CMD.EXE, you should probably not challenge them with alternatives. We wouldn't want you or PortableApps to get a bad name.
On the other hand, that locked-down machine should be a good one for testing, to see what those restrictions do to the PA platform, with a view toward eliminating proscribed behaviors where possible.
MC
I think of myself as an IT professional.
When I am working on site I make no secret of the fact I use portable apps.
I have even converted some customers to use some products.
I am loathed to even try and "learn" a new shell (perl etc) this post was just triggered from trying to get this https://portableapps.com/node/9227 to work.
Apache was erroring out, but I could not see stdout as I could not get a command shell.
Aside from that I have had no problems running portable apps on locked down PC's.
Ross
I didn't mean to offend.
If a workstation is locked down to the extent of not allowing cmd.exe to run, that should probably be the end of it. It would be improper to try to get around the restriction.
My mention of other shells was mostly intended to be humorous. I don't really think they would work in a restricted environment, although it might be interesting to see ... on my own locked down machine, not someone else's.
There are some advantages to using a different shell, if one is familiar with it. That would be the other reason for experimenting to see what it would take to set up an alternative to be available when running PortableApps.
Autoit and some other compiled scripting languages might give you access to stdout without going through cmd.exe (someone more familiar with it than I would need to say). Or maybe the Launcher for the app that isn't working could accept a parameter to tell it to save lots of error information to a log file, including any stdout or stderr it can intercept. But that's just speculating. I wouldn't be surprised if cmd was used in the background for that on normal machines...
Sorry.
MC
The point I was highlighting was that a lot of the general comments are about doing things "under the radar". I prefer to highlight how useful PA can be.
Just today a customer was complaining about not being able to FTP from his new PC, 30 seconds later......
It would be "interesting" to see if a sell replacement could be made portable, eg, copy a perl folder onto my USB. Downside is I have not written anything in perl in about 10 years !!!!