A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » General XP issues or comments
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

What Windwos freeware adds powerful "phone Susan" & "vipw" commands?



 
 
Thread Tools Display Modes
  #1  
Old July 5th 18, 12:45 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

What Windows freeware adds powerful "phone Susan" & "vipw" commands?
a. Start Run phone susan {enter} == outputs Susan's phone number
b. Start Run vipw {enter} == decrypts an encrypted password file

This is a common need that everyone can benefit from your solution.

More detail:

1. Start Run vipw
The goal is that the passwd.txt file is an encrypted plaintext file
containing whatever data you want to put in the cleartext file, where, for
this example, passwd.txt contains passwords that you wish to keep handy but
which you wish to keep encrypted until you need it.

2. Start Run phone Susan
The goal is that the phone.txt file is a plain text file containing as many
lines as you want which contain the case-insensitive characters "susan" in
them (essentially it's a "grep -i susan" command).

Note: It's not at all hard to get any command to work in the "Start Run"
box if we simply set up an "App Paths" "exe" key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\vipw.exe
Where the value of the "vipw.exe" key is, oh, say, "C:\path\command.bat"

The question is what "command.bat" will do these commonly needed tasks?
A. Decrypt & open a given plain text file (after entering the password)
B. Grep a given plain text file for the given keywords

What I'm not asking for:
a. Cygwin (because it's too complex)
b. Win10 Bash Shell (same reason as above)
c. Any solution that won't work from a single "Start Run" command.
(i.e., we don't want to pop up a complex GUI like Veracrypt is)

What Windows freeware adds powerful "phone Susan" & "vipw" commands?
a. Start Run phone susan {enter} == outputs Susan's phone number
b. Start Run vipw {enter} == decrypts an encrypted password file
Ads
  #2  
Old July 5th 18, 05:15 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Mark Blain
external usenet poster
 
Posts: 84
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

Arlen Holder wrote in
news
What Windows freeware adds powerful "phone Susan" & "vipw"
commands? a. Start Run phone susan {enter} == outputs Susan's
phone number b. Start Run vipw {enter} == decrypts an
encrypted password file

This is a common need that everyone can benefit from your
solution.

More detail:

1. Start Run vipw
The goal is that the passwd.txt file is an encrypted plaintext
file containing whatever data you want to put in the cleartext
file, where, for this example, passwd.txt contains passwords that
you wish to keep handy but which you wish to keep encrypted until
you need it.

2. Start Run phone Susan
The goal is that the phone.txt file is a plain text file
containing as many lines as you want which contain the
case-insensitive characters "susan" in them (essentially it's a
"grep -i susan" command).

Note: It's not at all hard to get any command to work in the
"Start Run" box if we simply set up an "App Paths" "exe" key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\vipw.exe
Where the value of the "vipw.exe" key is, oh, say,
"C:\path\command.bat"

The question is what "command.bat" will do these commonly needed
tasks? A. Decrypt & open a given plain text file (after entering
the password) B. Grep a given plain text file for the given
keywords

What I'm not asking for:
a. Cygwin (because it's too complex)
b. Win10 Bash Shell (same reason as above)
c. Any solution that won't work from a single "Start Run"
command. (i.e., we don't want to pop up a complex GUI like
Veracrypt is)

What Windows freeware adds powerful "phone Susan" & "vipw"
commands? a. Start Run phone susan {enter} == outputs Susan's
phone number b. Start Run vipw {enter} == decrypts an
encrypted password file



For (2), your "command.bat" could look something like:

@echo off
find /i "%1" C:\path_to_my\phone.txt
pause


For (1), your best choice really would be a GUI password manager like
KeePass (https://keepass.info). You could encrypt "password.txt"
with most any freeware compression program and open the encrypted
file with a Start- Run command to READ the passwords inside, but not
to EDIT them: for that, you'd have to extract the text first and re-
encrypt it afterward. That's not convenient or secure.
  #3  
Old July 5th 18, 09:29 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
R.Wieser
external usenet poster
 
Posts: 1,302
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

Arlen,

1. Start Run vipw
The goal is that the passwd.txt file is an encrypted plaintext file
containing whatever data you want to put in the cleartext file, where,
for this example, passwd.txt contains passwords that you wish to keep
handy but which you wish to keep encrypted until you need it.


The last time I thought that would be handy, I simply used any of the
"zipping", command-line programs that are floating around the web. "Zip"
the cleartext file using a password, do the reverse to get the file back.

For the last part you do not even need a batch file, everything can be put
in a shortcuts argument.

Its not really secure though ... (you're re-creating the origional cleartext
file, which you need to remember to delete - every time)

And have you already thought of using something like 7z ? It allows you to
put one-or-more files into an encrypted conrtainer, and extract them by
simply double-clicking the resulting .7z file. Easy as pie. No special
and/or extra stuff needed (apart from 7z ofcourse).

2. Start Run phone Susan

[snip]
(essentially it's a "grep -i susan" command).


You gave the answer yourself (put it into a batchfile or, as above, into the
argument of a shortcut). Whats wrong with that approach ?

But I have to say it: "phone {name}" only returning the number of a person
without actually phoning them definitily will confuse the heck outof a
run-of-the-mill user ...

Also, XP has got a program called "wab.exe" (Window Adres Book). As far as
I can tell (see) you can even tell it to, among others, start dialling
(don't know how that exactly works, never used the feature)

And before you compain that its not encrypted, you did not ask for that. :-)

What I'm not asking for:

....
b. Win10 Bash Shell (same reason as above)


You're still dumping your W10 centric questions into a fully unrelated
newsgroup I see. :-(

Suggestion: *first* make sure it will work for your (version of the) OS.
Only than consider to extend it to other area's. *especially* as you have
zero knowledge of if what you come up with (used (batch) commands, etc.)
will actually work (or not) on XP. (or if command valid on XP will (still)
work on W10).

c. Any solution that won't work from a single "Start Run" command.


Lol. Thats why you have batch and scripting languages available. So that
you can wrap a lots of commandlines into a script, making it look as a
single command.

Regards,
Rudy Wieser


  #4  
Old July 5th 18, 07:56 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

On 5 Jul 2018 04:15:43 GMT, Mark Blain wrote:

For (2), your "command.bat" could look something like:

@echo off
find /i "%1" C:\path_to_my\phone.txt
pause


Thank you!
Your suggestion worked perfectly on the first pass!

USE MODEL:
a. Start Run phone susan {enter}
b. Instantly pops up a window containing the given "grep" results.
c. Pressing return in the resulting window makes those results go away.

Here's how to set that up in three easy steps:
1. Create a data file anywhere of any name (usually ending in ".txt")
containing text rolodex information, for example:
C:\path\data.txt
2. Create a batch file anywhere of any name (usually ending in ".bat")
containing the given grep command:
c:\path\grep.bat
Where that batch file contains the suggested three lines:
@echo off
find /i "%1" C:\path\data.txt
pause
3. Create an "AppPaths" string key of any name (always ending in ".exe")
which points to that batch file, for example:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\phone.exe
Default="c:\path\grep.bat"

Obviously you can use any file & key names you like.
The doublequotes are only needed if you have long names or spaces in the
path to the batch file.

Note that for example purposes, I gave each of the three items different
names, but there is no reason you can't use similar names, such as:
1. c:\path\phone.txt
2. c:\path\phone.bat
3. App Paths = phone.exe

Note: The key named "phone.exe" simply defines the name of the command that
you will run. There is no need for a file named "phone.exe"; the ".exe"
extension is simply a mandatory requirement of the "App Paths" key.

Thank you for adding to the tribal knowledge of this newsgroup!
  #5  
Old July 5th 18, 09:57 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
R.Wieser
external usenet poster
 
Posts: 1,302
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

Arlen,

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 ?

In other words: when making a "usually" suggestions like that (making it
appear its not necessary), make goddamn sure that another way also works.

c:\path\grep.bat


Any name, as long as its "grep.bat" ? Maybe you ment that as a suggestion,
but if so you forgot to mention it.

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).

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). 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".

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. :-)

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.

the ".exe" extension is simply a mandatory requirement of the
"App Paths" key.


Actually ? It isn't.

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. :-(

Regards,
Rudy Wieser

P.s.
I can imagine that you want to help other people / show off your knowledge.
But please, make sure that what you offer is actually correct. 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 :-((

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". :-)

It allows you to move the three files around, and you only need to change
the path to the batch file itself.

Works under XP. *Might* work under W10. Yours to check.



  #6  
Old July 6th 18, 01:11 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

On 5 Jul 2018 04:15:43 GMT, Mark Blain wrote:

For (1), your best choice really would be a GUI password manager like
KeePass (https://keepass.info). You could encrypt "password.txt"
with most any freeware compression program and open the encrypted
file with a Start- Run command to READ the passwords inside, but not
to EDIT them: for that, you'd have to extract the text first and re-
encrypt it afterward. That's not convenient or secure.


This is a much harder problem to solve, so I thank you for your astute
advice on the harder problem of efficiently accessing the users' passwd
file from the "Start Run" command interface.

I agree it's "messy" having to add the step of securely deleting the
plaintext file after the fact.

Ideally, you want to decrypt the ciphertext passwd file into memory,
visibly view or manually edit the resultant cleartext, and, when you close
down the viewing/editing window, to automatically encrypt the results and
then save only the newly encrypted results to a file, all in one fell swoop
(leaving no cleartext file except that which may remain in memory).

There are command-line encryption questions for Windows:
https://superuser.com/questions/434716/looking-for-command-line-encryption-utility-for-windows
Where not only 7zip, but also openssl, pgp/gpg, & truecrypt/viacrypt
suggestions have been offered.

None of those are native to Windows, but the cipher command looks useful:
https://www.windows-commandline.com/cipher-command-line-encryption-utility/
c:\windows\system32\cipher.exe

In that article on Windows native command-line encryption are examples:
To encrypt a file, use: cipher /A /E filename
To decrypt a file, use: cipher /D fileName

I'm sure payware solutions would work, such as this one example:
http://www.aeppro.com/products/screenshots/how-to-automate-file-encryption-from-windows-command-line.shtml
But the goal is to accomplish the task "well enough" using free methods.

I will try out some of these solutions, where they all seem to do the job!
  #7  
Old July 6th 18, 01:11 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

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.
  #8  
Old July 6th 18, 03:19 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

On 5 Jul 2018 08:29:05 GMT, R.Wieser wrote:

Its not really secure though ... (you're re-creating the origional cleartext
file, which you need to remember to delete - every time)


SOLVED!

Thanks for everyone's purposefully helpful advice.
Both commands worked fine in their very first tests today!

This brings up a ciphertext passwd file on Windows:
Start Run vipw {Enter}

This greps a plaintext database file on Windows:
Start Run phone susan {Enter}

My next steps will be to try to figure out how best to network those files
so that one file serves all the compute devices, whether they're Linux,
Windows, Android or iOS.

If you have advice as to how to accomplish that goal, please let us know!
  #9  
Old July 6th 18, 03:51 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

On 6 Jul 2018 01:58:04 GMT, Arlen Holder wrote:

Add the custom "App Paths" registry entry:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
vipw.exe
Default = c:\app\editor\passwd\keepass\KeePass.exe


In the previous post, the App Paths key was set to the executable.
In this post, I tested setting the App Paths key to the passwd file.

Add the custom "App Paths" registry entry:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
vipw.exe
Instead of a default to the KeePass executable:
Default = c:\app\editor\passwd\keepass\KeePass.exe
I changed the default to the passwd file itself:
Default = c:\data\private\passwd.kdbx

Both methods work fine, where the latter method means that I can probably
set up the location of the master passwd file so that a single ciphertext
passwd file can be accessed by all machines on the network.

For example, something like this network path might work?
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
vipw.exe
Default = \\machine\share\path\passwd.kdbx

I readily admit that I don't know Windows (SMB?) networking well, so if
someone has advice for setting up that capability to store a single
ciphertext passwd file on a network share, please advise so that this
"vipw" command will work on all the systems, whether Android, iOS, Windows
or Linux to access the single master passwd file on the LAN.
  #10  
Old July 6th 18, 01:08 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
R.Wieser
external usenet poster
 
Posts: 1,302
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

Arlen,

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


I already guessed that that might have been the idea behind what you said,
but the way you said it could be explained as *any* extension ("executable"
or not) would be acceptable. And we both know that that won't work. :-)

Perhaps I could have said "Create an executable file" or just
"Create a file", since the file doesn't even need to be executable.


You're making the same mistake he The file really needs to be of a type
that is, in this case, recognised either as a true executable, or linked to
one of the several scripting engines your OS has available.
In other words: the extension needs to be from a (very) small subset of
possible ones.

As another example, I just created this system-wide "bookmark" command:


Yes, that works too. Because the ".htm" extension is linked to a program
(the browser). Pick an extension that is not a program or linked to one,
and you will get a "don't know how to handle that" error message. :-)

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.


Not quite. I meant to say that when you indicate you can use any name that
you should explain (of sorts) why you are using a specific one. Even if its
just a short "For my example I've choosen to use the name {whatever}" one.

Particularly for noobs who may not have their filename extension
viewing turned on by default.


Yes, particulary there.

It should be noted that I store my "data" files in a public/private
data hierarchy


:-) That would have been a good "I suggest ..." addition to your tut.
Currently the poor noob has no idea where to store such files (and why), and
could easily choose an existing folder or create a bunch in the root of C: -
which could cause problems (and is ugly) ...

And as long as you are talking about a users own place to store such files,
XP offers place for such a folder under the "C:\Documents and
Settings\{username}" (as available in the %USERPROFILE% environment
variable) branch.

Had I chosen explicit paths, people would have complained about
the paths.


True, and most likely I would too. :-)

The point is that *you* do not make a choice, but instead you provide a set
of possible options (does not even need to be exhaustive!) and make
suggestions to what you think would be a good one - and explain why
ofcourse.

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";


Thats looks like a good one, but does not indicate exctly what it will be
"looking up".

I think I would go for something like "PhoneNumber" or just "PhoneList".
Much more indicative. But again, offer it as a suggestion.

And by the way, have you ever thought to include a "how to use this program"
output when no (or possibly the "/?") argument is provided ? Would be
both helpful for a first-time user, as well as a reminder for a long-time
(but not all that frequent) user.

Luckily, in this case, there is no "exe" file.


And pray tell, how do you know that ? Your batch file is supposed to work
on *other peoples* computers, about which you should not make assumptions
like that.

Also, its not only the exe extension which could cause problems. *Any*
extenson which is either directly executable or links to a program that will
handle it could cause the same problems. And FYI, my rather default XPsp3
installation has got a "phone.inf" file in the windows folder tree - with an
"install" verb shown in the rightclick context menu (as in: could muck up
your computer but good). Luckily not in the searchpath, but still ...

The "phone.exe" in the example is merely the name of a registry key.


I know. But as mentioned above, do the noobs know that too ?

If I would have written such a suggestion in the/my full defensive mode I
would have suggested to pick a name that does not already exist - by either
first searching for it, or just, before using it, typing the name in the
"run" box (a bit dangerous, but if no error pops up it must already be in
use - as an external program *or* "internal" command. Maybe even already
specified in another "App path" entry).

Have you ever thought of just placing the .BAT command in a folder
named in the search path ? Way easier. :-)


Way easier?
Not really.


Yes, really.

Your whole "step #3" (mucking around with the registry) can be skipped when
you put the batchfile into the C:\Windows directory, or any of the other
paths named in the %PATH% environment variable.

I would not directly advice it (as my suggestion below it already
indicated), but it is definitily easier.

The advantage of the App Paths method is that the command doesn't
pollute your $PATH


Adding a single folder (as in: *once*) to that %PATH% (where all such and
similar stuff can be stored) constitutes to pollution ? I learn something
new every day. :-D

And by the way: I've "polluted" mine over a decade that way (or two. Can't
remember), and I have not seen it (try to) procreate. Its precence in that
path variable also acts as a quick reminder where I should put/store further
enhancements (so they do not get put into a gazillion different folders all
over the drive(s) )

The advantage of the method you suggest is that you don't need
to create an App Paths key.


I think you mean here that "you don't need to pollute the App Paths branch".
(hint: All monks of the same order should have to wear the same habit).

The third advantage of using a folder is that its easier to manage:
Deleting a program/script there means its gone. No extra registry-editing
cleanup stuff needed.

The next advantage is that the actual program can be easily be found back,
which you cannot do when using your renaming trick using the App Path ...

the ".exe" extension is simply a mandatory requirement of the
"App Paths" key.


Actually ? It isn't.


Teach me (and us) something.


Well, why don't you try it yourself ? Create, for example, the entry
"foobar.blurb" {1} and make it point to your "phone.bat". Than go to your
"run" textfield, and enter the name just like that but *including* that
extension, and press enter (or click OK). What happens ?

{1} See what I did there ? The used filename, but in this case
specifically the extension (as that is what we are talking about) is an
*example*. It indicates that there might well be more doing behaving the
same.

And by the way, including the extension of an executable, batch or other
scripting forces the OS not to apply its own precedence rules (read: have it
guess what the extension is supposed to be), and allows you to purposely
execute, in a console window, a {name}.bat when a {name}.exe also exists in
the same folder.

Does anyone reading this have a *different* last four characters in
*any* entry in the "App Paths" section of the system registry?


That was not the point.

You where making the mistake of regarding not seeing the presence of
something as it being not allowed. And you where as cocky as to put it
forward as it being a rule. Without actually checking it. :-(

That is how disinformation comes to be. Often by basically well-meaning
people (you) making unbased assumptions and than presenting them as facts to
others. Which, when especially when they are the noobs you are targetting
(read, not knowing how/ready yet to verify such claims) are likely to
propagate them.

If you have a working example that does *not* end with ".exe", that
would be very interesting indeed.


See above.

Huh?
Nobody said anything about a "grep.exe" file existing.


Damn! You're right! You just named the batchfile "grep", but used the
program "find" in it. My apologies.

But my excuse for that is .... Nah, no excuses. I misread, and thats
fully on my own head.

HINT: That's why MSoft invented the "App Paths" key in the first place.


Hint: you could already to that in the DOS days by, in some folder that is
part of the searchpath, creating a batch file "linking" to the target
executable, and when Windows came to be by replacing the batchfile with a
..LNK one.

I have absolutily no idea what the "App paths" offers that either of the
above two do not. Do you ?

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


In that case, make sure to mention that what you post are *not* tutorials or
step plans to be used by anyone, but just your personal experiences while
dabbing into something new (and showing it).

Currently your "benefit of the tribal archives" is to poisson it with
half-truths and full guesses (as shown in the above), which do not help
anyone, least of all the poor noob which thinks you are experienced and know
what you are talking about.

But please, make sure that what you offer is actually correct.


A clarification and a correction are two different things.


I was not talking about either of them.

You mentioned, for example, that a 'grep.exe' is problematic,
where I clarified that there is no file named 'grep.exe' that was
proposed.


The problem with that is that while it is true for *your* machine, it does
not need to be for any of the machines reading your message (mine does have
it. Probably came with an installation of (a commandline version of) C or
C++ ).

What I *tried* to tell you is to start thinking defensively. Think beyond
your own and try to take your audiences computers into consideration too.

If you do not than you are in fact writing for an audience of one: You.

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.


Nope, neither. It was just me recognising the problem it could (and
probably would) create as soon as I put my eyes on it, and trying to make
you aware of it.

And strange though: Seeing that you *know* about grep being a program, you
still thought it would be a good idea to create a batch file with the same
name, regardless of the possiblility of a clash ...

And no, more detail is in no way a good replacement to a bit of common sense
in filenaming.

To cover all possible areas of confusion is noble


Lol. Thats exactly the very opposite of what you have been doing, and not
at all what I tried to say.

Just start with *not* suggesting (by omission) that what you write down is
the only possible area. Make the reader / your audience aware that there
are others, even if you do not (even) explicitily name them. They are not
dumb, they will be able to respond with a request for more info, or maybe
even just searching google.

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 keep using that "pollute" word. Are you purposely trying to vilify my
suggested method ? Why ?

And thats apart from me having indicated that neither your App Path method,
nor my suggested addition of a single entry(!) to the searchpath method is
even needed ...

In short, you are comparing two complex methods, while ignoring a much
simpler one. :-o :-(

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.


The problem is, *they* just followed what you posted to the letter, and did
nothing wrong. Its *your* information which contains the errors,
half-truths and full guesswork - all presented as archive-worthy material.

And thats exactly the other problem: what happens when those people find
your posts in those "tribal archives", long (or short) after you moved on ?
Yes, than it will be the thanwhile smartasses in this group who have to
clean up your mess.

And pardon me, the *others* need to man up, confess they did something wrong
and and ask ? Even when all they did was to follow your "this is how I did
it" (even if you have never presented it as such) to the letter ? Where
is *your* responsibility in it ?

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.


Wrong answer.

What I showed you there is, as mentioned, an approach to do away with having
to change change paths at different locations (and in this case, in a
script) just to get something, after moving it, working again. It could
even cause your batch script(s) to become copy-paste-and-work, instead of
having to edit them too.

In short, I thought you would see the benefits of it. I guess I was wrong.

Hey, nice talking to you. I'm going to do something else now.

Regards,
Rudy Wieser


  #11  
Old July 6th 18, 03:25 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

Let's stop wasting everyone's time playing silly semantic games.
Let's instead, move the technical ball forward.

What we want now, is to have a *single* encrypted passwd file for the LAN.
It would need to work with all machines & mobile devices on the LAN.

That requires some kind of central "server".

Perhaps that's the native SMB server inherent in Windows?
\\server\share\path\file.ext

Or perhaps that's some other server, e.g., ftp, or http?
http://192.168.1.10/path/file.htm

What do you think?

Now that we have the original tasks both successfully working perfectly on
the first pass on any given Windows machine, what is your astute
recommendation for consolidating both the passwd and data files as a single
file accesssed from all Windows, Linux, Android, and iOS machines on your
local LAN?
  #12  
Old July 6th 18, 05:06 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
nospam
external usenet poster
 
Posts: 4,718
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

In article , R.Wieser
wrote:




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


In that case, make sure to mention that what you post are *not* tutorials or
step plans to be used by anyone, but just your personal experiences while
dabbing into something new (and showing it).

Currently your "benefit of the tribal archives" is to poisson it with
half-truths and full guesses (as shown in the above), which do not help
anyone, least of all the poor noob which thinks you are experienced and know
what you are talking about.


^^ this ^^



You mentioned, for example, that a 'grep.exe' is problematic,
where I clarified that there is no file named 'grep.exe' that was
proposed.


The problem with that is that while it is true for *your* machine, it does
not need to be for any of the machines reading your message (mine does have
it. Probably came with an installation of (a commandline version of) C or
C++ ).

What I *tried* to tell you is to start thinking defensively. Think beyond
your own and try to take your audiences computers into consideration too.

If you do not than you are in fact writing for an audience of one: You.


that's exactly what he's doing.
  #13  
Old July 6th 18, 05:06 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
nospam
external usenet poster
 
Posts: 4,718
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

In article , Arlen Holder
wrote:


What we want now, is to have a *single* encrypted passwd file for the LAN.
It would need to work with all machines & mobile devices on the LAN.


no, that's what *you* want.

others may prefer using an established password manager that is known
to be secure, without the numerous pitfalls and limitations of using an
encrypted text file, which can sync across multiple devices without any
extra effort on the user's part along with numerous other features.
  #14  
Old July 7th 18, 12:30 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
J. P. Gilliver (John)[_4_]
external usenet poster
 
Posts: 2,679
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

In message , R.Wieser
writes:
Arlen,

[]
Currently your "benefit of the tribal archives" is to poisson it with

[]
Sounds fishy to me (-:.

(On a more general note: I've found it more sanity-protective to
killfile this person whenever I spot a new alias of his. I too have
spent much time in discussion with him, thinking I was helping the
general good. But life's too short. Sadly, I am going to continue to let
the "archives" be "poissoned", to preserve my own sanity.)
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)[email protected]+H+Sh0!:`)DNAf

Imagine a world with no hypothetical situations...
  #15  
Old July 7th 18, 01:03 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Arlen Holder
external usenet poster
 
Posts: 466
Default What Windwos freeware adds powerful "phone Susan" & "vipw" commands?

On 7 Jul 2018 11:30:16 GMT, J. P. Gilliver (John) wrote:

Sounds fishy to me


J.P. Gilliver,

*Do not again prove yourself to be a lowly coward devoid of reason.*

Do you deny the two capabilities are generally useful?
a. The ability to easily "grep" a rolodex file, and,
b. The ability to easily access a secure password file.

If you deny, then what do you think is not useful about those capabilities?
In fact, to the point what have *you* contributed to those capabilities?

I know the answers to both those questions.
So does everyone who is logical.

Let's hear your defense of your cowardly post, completely devoid of reason.

Unless, you're still a lowly coward, you will truthfully state the answers.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 11:48 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.
Copyright 2004-2023 PCbanter.
The comments are property of their posters.