mask password on command line?

[djbitchpimp]

I need a simple way to mask a string (password field) while inputing
characters on the command line. It can either cover the string with '*'
or just not advance the cursor.

Does anyone have any ideas?

 

[Real Gagnon]

I need a simple way to mask a string (password field) while inputing

characters on the command line. It can either cover the string with '*'
or just not advance the cursor.

Does anyone have any ideas?

One idea is to start a thread to print backspace characters to the console
to hide the current input.

Example at :
http://www.rgagnon.com/javadetails/java-0375.html

Bye.

 

[Roedy Green]

I need a simple way to mask a string (password field) while inputing
characters on the command line. It can either cover the string with '*'
or just not advance the cursor.

Does anyone have any ideas?

You could write a small MASM or C command line utility to do it and
leave the result in a file or the set environment.

You could use 4NT as your command processor. It has such as beast
called INPUT /Password

see http://mindprod.com/jgloss/fornt.html

You could delay entering the password until the program starts, then
you have access to Java's JPasswordField

you could hire me to solve your problem for $50 US.

 

[Andrew Thompson]

Just to clarify, it is a console application - all input and output is
done on the console.

What is that? A *rule*?

I do not get it.

So JOptionPane/JPassWordField will not work.

*Technically*, as the problem has been described to my
understanding, it will. The code example I posted started
from 'the console', and ended handing control back to it.

Where's the problem?

 

[Andrew Thompson]

....
What exactly is a console application?

A command-line application doesn't use Swing or AWT. In most cases it
doesn't know or care if a GUI is available (think telnet or ssh
sessions to a remote box without X or another GUI).

'Headless' environments? Yes that would be a problem.

I had not thought the Headless enviroment would apply to
this situation (I was thinking 'Headless - batch files only'),
and if it does, then yes, that completely explains why GUI
components are unavailable/unusable.

 

[John Currier]

What is that? A *rule*?

I do not get it.


*Technically*, as the problem has been described to my
understanding, it will. The code example I posted started
from 'the console', and ended handing control back to it.

Where's the problem?

I believe what you just described is a GUI program, not a command-line
(i.e. console) program. As soon as you introduce a graphical user
interface then, by definition, you've got a GUI.

John
http://schemaspy.sourceforge.net

 

[Gordon Beaton]

Just to clarify, it is a console application - all input and output is
done on the console. So JOptionPane/JPassWordField will not work.

If you can control the console input mode (for example, with stty on a
unix-like platform) then you can turn off local echo as another poster
has already suggested. I've posted sample code to do this several
times in the past:

http://groups.google.com/group/comp.lang.java.programmer/msg/a132c7feda18187a

/gordon

 

[Roedy Green]

Just to clarify, it is a console application - all input and output is
done on the console. So JOptionPane/JPassWordField will not work.

Also keep in mind the DOS box console in a window of a program
referred to as the command interpreter. I think the Java console is
just a window of a Java Application. They have almost nothing in
common other than a similar Spartan LAF.

You can't run programs in the Java console. None of the console
display and colour configuring commands affect it. It is unaffected by
your font and window size choices in the command interpreter.

 

[Roedy Green]

What is that? A *rule*?

One problem with using JPasswordField is as soon as you use even that
one widget you will drag in a ton of related GUI junk that will stay
loaded till the end of execution.

I think the easiest answer is a little C utility to collect the
password and stuff it in the environment where you can extract it and
add it as a system property or argument to the command line.

See http://mindprod.com/jgloss/environment.html

 

[Andrew Thompson]

One problem with using JPasswordField is as soon as you use even that
one widget you will drag in a ton of related GUI junk that will stay
loaded till the end of execution.

(shrugs) ..and what? It takes but a moment, and what does it
matter if it loads a few Meg of classes that remain in memory?
I'd posit that any program that crashes with OOME's when a
JOptionPane is shown, is already suffering memory problems.

( Your words carry the taint of 'premature optimisation',
the way I read them. )

 

[Roedy Green]

If you can control the console input mode (for example, with stty on a
unix-like platform) then you can turn off local echo as another poster
has already suggested. I've posted sample code to do this several
times in the past:

I don't think that would work in windows. Local echo suppression would
be a command to the command interpreter which is not even necessarily
running at the point your program is. If it works in Unix, that means
Java implements the console in a more native way.

 

[Gordon Beaton]

I don't think that would work in windows. Local echo suppression
would be a command to the command interpreter which is not even
necessarily running at the point your program is. If it works in
Unix, that means Java implements the console in a more native way.

Java doesn't implement the text console that it runs in on either
platform, the OS does. Java reads stdin from a file descriptor in both
cases.

It has nothing to do with the command interpreter either. The OS
provides the console as a logical device (e.g. /dev/tty on unix, con:
or something like that on windows) that the process communicates with
through the file descriptor. Changing the console mode is a simple
matter of configuring the device to behave differently (assuming that
it has that capability).

On Unix and similar platforms like Linux, there is a set of APIs for
configuring the console (unavailable to Java), and a command line tool
"stty" (which can be used either from within the Java application, or
in the shell prior to starting the application).

Potientially the mechanism should work on Windows if the console has
such a capability and there is a way to manage it from an application,
however I have no idea what facilities might be available. That
doesn't prevent me from posting a solution that is sufficient for some
users though.

/gordon

 

[Thomas Weidenfeller]

Just to clarify, it is a console application - all input and output is
done on the console. So JOptionPane/JPassWordField will not work.

Java is not well suited for console applications at all. If fact, it
provides nothing, absolutely nothing for a serious console application.

Consider

- Another language - seriously

- An additional, JNI based, platform-specific text API library like
JCurses, or

- to change the application to a GUI application.

/Thomas

 

[Roedy Green]

( Your words carry the taint of 'premature optimisation',
the way I read them. )

Poor old Knuth, when he dies will roll in his grave, when he learns
how his words have been interpreted so often to mean "Writing slow
programs deliberately is a mark of virtue." like the way people in
medieval times bragged about how rarely they bathed.

It is not wicked to know what will run quickly or slowly or to even
spread that knowledge. If you can optimise early without extra effort
that is a GOOD thing. That is not premature.

"Premature" does not mean "early" or "design-stage".

What Knuth was railing against was micro coding in optimisations that
a modern compiler does for you, making the code harder to read and
maintain, without even determining if that code was a bottleneck.

 

[Roedy Green]

Java doesn't implement the text console that it runs in on either
platform, the OS does.

how do you know this?

Obviously the command interpreter is not there.

 

[Gordon Beaton]

how do you know this?

Basic understanding of how an operating system works. Stdin and stdout
look the same for every process. Redirection works as expected,
without any help from the application. No process creates the
environment it's run within. Some experience with windows too, I'm
afraid.

I don't have an authoritative document to refer to if that's what you
mean.

/gordon

 

[John Currier]

One problem with using JPasswordField is as soon as you use even that
one widget you will drag in a ton of related GUI junk that will stay
loaded till the end of execution.

I think the easiest answer is a little C utility to collect the
password and stuff it in the environment where you can extract it and
add it as a system property or argument to the command line.

See http://mindprod.com/jgloss/environment.html

If you add the password to the command line then anyone on the machine
can see it (assuming Unix) by looking at the output of ps (another
extremely useful command-line tool).

John
http://schemaspy.sourceforge.net

 

[zero]

(shrugs) ..and what? It takes but a moment, and what does it
matter if it loads a few Meg of classes that remain in memory?
I'd posit that any program that crashes with OOME's when a
JOptionPane is shown, is already suffering memory problems.

( Your words carry the taint of 'premature optimisation',
the way I read them. )

I think you (and some other people) are forgetting that some platforms
simply do not have a graphical interface. It is perfectly reasonable (and
in fact quite common among expert users) to install Linux without
installing the graphical components. And you would still have a completely
functional multi-user, multi-tasking environment - just without the
windows. And without an underlying window manager, Java cannot show any
frames, dialogs, etc.

 

[Andrew Thompson]

....
I think you (and some other people) are forgetting that some platforms
simply do not have a graphical interface.

Headless. No (not forgetting). I mentioned it on a variety
of other sub-threads you seem to have missed.

We are now talking about use of JOptionPane in other environments.

(And FWIW - I was never entirely clear, and no longer care,
if the OP's environment *is* 'headless')

 

[Andrew Thompson]

Poor old Knuth, when he dies will roll in his grave, when he learns
how his words have been interpreted so often to mean "Writing slow
programs ..

If it were 'slow', I would not recommend it.
What are your benchmark's revealing?
How much time does it take?

<but then..>
What is your definition of slow?
</but then..>