On 5 Jul 2018 20:57:40 GMT, R.Wieser wrote:
2. Create a batch file anywhere of any name (usually ending in ".bat")
Have you ever tried to start a batchfile *not* ending in .BAT ? And, what
was the result ?
Thanks for that clarification.
What I had meant was that the actual file being executed didn't have to be
a batch file. It could be any "executable" file, where, batch is simply the
most common type.
Perhaps I could have said "Create an executable file" or just "Create a
file", since the file doesn't even need to be executable.
In other words: when making a "usually" suggestions like that (making it
appear its not necessary), make goddamn sure that another way also works.
I appreciate the suggestion.
As another example, I just created this system-wide "bookmark" command:
Start Run bookmark {Enter}
Where the App Paths "bookmark.exe" key pointed to an ".htm" file:
Default=c:\path\bookmark.htm
And where the result is that the bookmarks open up in the default browser.
Any name, as long as its "grep.bat" ? Maybe you ment that as a suggestion,
but if so you forgot to mention it.
I appreciate the critical look at the note where I guess what you're saying
is that once you decided on a name, you have to actually use *that* name in
the App Paths key, which is true.
And a problem with that is that .BAT is an extension known to the system,
just as .EXE . In other words, using both of them in the same folder will
cause confusion for the user (which one is started when no extension is
provided).
This is also a very good point.
Particularly for noobs who may not have their filename extension viewing
turned on by default.
It should be noted that I store my "data" files in a public/private data
hierarchy which is completely separate from my batch file executable
hiearchies so the word "path" in each description is really "path1" and
"path2" and "path3" in my case - but - the user can store their files
anywhere that makes sense to them.
Had I chosen explicit paths, people would have complained about the paths.
Also, naming the batchfile the same as an already existing command (grep.exe
vs grep.bat) is a pretty sure receipe for disaster (at some time or
another).
Based on the separate input from you about "phone" being thought of as a
verb, a good name for the command could possibly be "lookup"; but again,
the user can use any name they like - which is why I purposefully used
three different names for the three steps, which was to show that the name
is an independent choice of theirs.
Since I chose explicit names, people complain about the names.
In the very least if the .BAT file is found before the .EXE (in
a search path) you will get something called a "fork bomb".
Luckily, in this case, there is no "exe" file.
The "phone.exe" in the example is merely the name of a registry key.
3. Create an "AppPaths" string key of any name (always ending in ".exe")
Have you ever thought of just placing the .BAT command in a folder named in
the search path ? Way easier. :-)
Way easier?
Not really.
Different?
Yup.
The advantage of the App Paths method is that the command doesn't pollute
your $PATH. The advantage of the method you suggest is that you don't need
to create an App Paths key.
Different methods.
Both easy.
And if you do not like that (and do explain your "I do not want to do it
that way" to whomever reads your post) and you have several additional
programs that you think really *must* start from the "run" entry box
(instead of from within a subfolder accessible from the "start" popup -
which I personally find rather handy) you could create a special folder for
those user-added commands, and add it to the systems "path" environment
variable. Needs only be done once, and does not clutter the registry.
Different methods work, I agree.
the ".exe" extension is simply a mandatory requirement of the
"App Paths" key.
Actually ? It isn't.
Teach me (and us) something.
Does anyone reading this have a *different* last four characters in *any*
entry in the "App Paths" section of the system registry?
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\*.exe
I don't.
If you have a working example that does *not* end with ".exe", that would
be very interesting indeed.
And as a last thing: grep.exe does not seem to be a part of a standard XP
installation. Meaning that you batch file will, again, not run on XP. :-(
Huh?
Nobody said anything about a "grep.exe" file existing.
Can you kindly clarify, as we *created* any file we needed in this example.
I've been using the App Paths keys since *before* WinXP days, as I recall,
where I don't see any reason this tutorial wouldn't work on Win95 for
example - since all you need is the "App Paths" key for it to work.
HINT: That's why MSoft invented the "App Paths" key in the first place.
I can imagine that you want to help other people / show off your knowledge.
My goal is simple which is
a) Ask a question
b. Get help on that question
c. Summarize the results for the benefit of the tribal archives
But please, make sure that what you offer is actually correct.
A clarification and a correction are two different things.
You mentioned, for example, that a 'grep.exe' is problematic, where I
clarified that there is no file named 'grep.exe' that was proposed.
That you were confused doesn't make it an error on anyone elses' part.
It just means you wish the ad-hoc Usenet post covered more detail.
Had I added more clarifying detail, others would have complained about the
detail since the assumption you're making is that people are confused so I
have to guess where they may become disoriented and confused.
To cover all possible areas of confusion is noble, but it's generally not
something that happens without testing in the real world on users who don't
know as much as we do about the App Paths key and how to use it
efficiently.
Also, the fact you would rather pollute the $PATH is not an error - it's
just a different way of accomplishing a similar task.
You seem to be complaining that the note didn't cover all possible ways and
all possible naming conventions, more than actual errors in the stated
steps.
And that
goes double (at the very least) for the poor noob who tries to follow your
suggestions/tutorials/step plans and than has absolutily zero idea why it
won't work :-((
If someone tries the steps, and if they don't work for them, I think they
can be man enough to simply ask what they did wrong.
P.p.s
Put the grep executable "data.txt" file into the same folder as the
batchfile, and, in that batch file, refer to them like this:
%0\..\grep.exe
%0\..\data.txt
Just remember *not* to name the batch file "grep.bat". :-)
There are plenty of ways to skin a cat.
The proposed method answers the proposed question.
Nobody said there aren't other ways to accomplish the stated task.
If you wish to write a quick note on how you'd accomplish the task so that
noobs can have their own rolodex command, I'd review it for you as would
others, I'm sure.
It allows you to move the three files around, and you only need to change
the path to the batch file itself.
Each method has pros and each method has cons.
If you want to write a quick note for others to follow that uses the
methods you propose, I don't think anyone would complain - so my suggestion
is that you write it and then people can choose what method they like best.
Works under XP. *Might* work under W10. Yours to check.
There's nothing in the method I wrote up that doesn't work in the Microsoft
Operating Systems *before* XP. All you need is the "App Paths" key and the
"find" command.