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!

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.

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.

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

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?

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.

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.

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)Ar@T+H+Sh0!:`)DNAf

Imagine a world with no hypothetical situations...

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.

John,

Currently your "benefit of the tribal archives" is to poisson it with
[]
Sounds fishy to me (-:.

:-p I had to google it to understand what you ment (poisson vs poison)

It one of those things that sometimes happens when English isn't your first
language and you're starting to get tired.

thinking I was helping the general good

Although my first thought was about Arlen himself, that also crossed my
mind - as a close second.

Sadly, I am going to continue to let the "archives" be "poissoned",

I don't think we have got any say in it I'm afraid. ...And I'm not so sure
it would be beneficial to usenet if we would have.

On the other hand, CLAX, which is moderated, still seems to do well.

Regards,
Rudy Wieser

Arlen,

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?

https://thenextweb.com/apps/2013/10/...d-the-desktop/

and

https://www.cio.com/article/3168902/...ows-files.html

.... or something like that.

Why ? Because you are asking us to help you to make something {1} you do
not even have a clue about of even half of what is all is involved to make
it become true. And that simply won't work.

{1} combine outof already existing parts ? You where not even clear about
that I'm afraid ...

Regards,
Rudy Wieser








What we want now, is to have a *single* encrypted passwd file for the LAN.

Question, who is that "we" you are talking about ? Are you working in a
team or for a company ? Or are you perhaps royalty ? If nothing of that
all, whats wrong with saying "I" (as in you, Arlen) ?

Second: You are adding (more) requirements. And by it you are
dropping/invalidating the origional question *and all the already-gotten
answers to it*. How's that for wasting someones (the well-willing people
who responded to you - including myself) time ?

It would need to work with all machines & mobile devices on the LAN

Kiddo, you definitily have not thought about what you said there, or are
fully clueless. Mobile devices (unspecified!) ? I must than assume you
mean those iThingies (iOS) and googlephones (Android) too.

In that case, good luck with finding either single executable which will
work the same on both windows and other OSes, or with finding a single idea
implemented for all of them. :-D

That requires some kind of central "server".
....
Perhaps that's the native SMB server inherent in Windows?
....
Or perhaps that's some other server, e.g., ftp, or http?

You already have ideas, go google them ! You might even find some other
possibilities too (in other words: do not expect us to do your work for
you).

And by the way: good luck with finding something that runs iOS that will
talk SMB. And there is a good chance it will not even run FTP nativily
either.

Now that we have the original tasks both successfully working
perfectly on the first pass ...

So, you expect us to do all the "will it work?" checking for you too ? If
so, whats than left for you to do ?

... on any given Windows machine

And what about all those mobile devices ? Don't expect to find Windows
there.

And thats *again* ignoring the differences between the versions of Windows,
which has been pointed out to you to exist even between the versions of the
OS related to the newsgroups you posted your message in.














"Arlen Holder" wrote in message
news
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?

In article , R.Wieser
wrote:

That requires some kind of central "server".
...
Perhaps that's the native SMB server inherent in Windows?
...
Or perhaps that's some other server, e.g., ftp, or http?

You already have ideas, go google them ! You might even find some other
possibilities too (in other words: do not expect us to do your work for
you).

And by the way: good luck with finding something that runs iOS that will
talk SMB. And there is a good chance it will not even run FTP nativily
either.

there are numerous ftp and smb apps for ios, either server or client,
as well as many other protocols.

where he needs luck is in getting his convoluted method to work
anywhere near as well as an existing password manager, or as secure.

On 7 Jul 2018 14:38:54 GMT, R.Wieser wrote:

https://www.cio.com/article/3168902/...ows-files.html

Thanks for that list of file-sharing apps between the operating systems.

None of the apps even comes remotely close to solving the stated networking
problem (since they all *copy* the file), but the first 3 of the 4 on that
list are still *nice to have* since they help the user copy files over WiFi
on their local network.

1. Send Anywhere (it *copies* the file, which isn't the question)
2. Feem v4 (it copies the file, which isn't the question)
3. Instashare (it copies the file, which isn't the question)
4. PushBullet (same, but this one requires registration)
https://www.cio.com/article/3168902/mobile-apps/4-apps-to-share-ios-android-and-windows-files.html

BTW, even though these don't even come close to solving the stated problem,
these apps are *nice* for "copying" files between devices though!

https://thenextweb.com/apps/2013/10/...d-the-desktop/

Thanks for that list of payware password managers.

Unfortunately, this list is even worse than the prior list
in that not one of those stores the password file on the LAN.

Summary:
1. Dashlane (shill to rent your passwords off the cloud)
2. RoboForm (shill to rent more than 10 passwords off the cloud)
3. mSecure (shill to rent your passwords off the cloud)
4. 1Password (shill to rent your passwords off the cloud)
5. LastPass (shill to rent your passwords after the 2-week trial period)
https://thenextweb.com/apps/2013/10/06/10-of-the-best-multi-platform-password-managers-for-ios-android-and-the-desktop/

It's just not anywhere in the problem set to store any of your private
data, particularly passwords, on the cloud.

What might work though, is to set up a "local cloud", and then see if the
password managers can work with that local cloud (but that's a lot more
effort to set up since server protocols are likely involved).

In summary, neither list even remotedly came close to solving the problem,
but while the second list was nothing but cloud shills, the first list does
seem, at least upon first inspection, to be worth checking out to solve a
*different* problem (which is cross-platform sharing of files).

thanks!

In article , Arlen Holder
wrote:


https://thenextweb.com/apps/2013/10/...atform-passwor
d-managers-for-ios-android-and-the-desktop/

Thanks for that list of payware password managers.

Unfortunately, this list is even worse than the prior list
in that not one of those stores the password file on the LAN.

false, and that's a five year old article that is very out of date.

there are several password managers that can store locally and not in
the cloud, including ones on that list at the time that article was
written.

in other words, you once again failed.

On 7 Jul 2018 13:32:27 GMT, R.Wieser wrote:

I don't think we have got any say in it I'm afraid. ...And I'm not so sure
it would be beneficial to usenet if we would have.

Did you see my latest Windows apnote on the efficient shutdown mechanism?
Start Run slideshut {Enter}

What did you think of it?
(HINT: You'll see that tutorial nowhere else on the net, but here.)