mask password on command line?

Discussion in 'Java' started by djbitchpimp@snowboard.com, Oct 19, 2005.

  1. Guest

    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?
     
    , Oct 19, 2005
    #1
    1. Advertising

  2. Real Gagnon Guest

    > 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.
    --
    Real Gagnon from Quebec, Canada
    * Looking for Java or PB code examples ? Visit Real's How-to
    * http://www.rgagnon.com/howto.html
     
    Real Gagnon, Oct 19, 2005
    #2
    1. Advertising

  3. Roedy Green Guest

    On 19 Oct 2005 14:49:40 -0700, wrote or
    quoted :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 19, 2005
    #3
  4. wrote:

    > 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, Oct 20, 2005
    #4
  5. John Currier wrote:

    > Andrew Thompson wrote:
    >
    >>John Currier wrote:
    >>
    >>> wrote:
    >>>
    >>>>I need a simple way to mask a string (password field) while inputing
    >>>>characters on the command line.

    >>...
    >>>The bugParade entry for this request has been closed with a 'fixed'
    >>>status:
    >>>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4050435

    >>
    >>It has generated a *lot* of interest and comments, but oddly,
    >>nobody mentioned the JOptionPane/JPassWordField path.

    ....
    > 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.
     
    Andrew Thompson, Oct 20, 2005
    #5
  6. John Currier Guest

    Andrew Thompson wrote:
    > wrote:
    >
    > > 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?


    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
     
    John Currier, Oct 20, 2005
    #6
  7. On 19 Oct 2005 21:17:01 -0700, wrote:
    > 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

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Oct 20, 2005
    #7
  8. Roedy Green Guest

    On 19 Oct 2005 21:17:01 -0700, wrote or
    quoted :

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

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 20, 2005
    #8
  9. Roedy Green Guest

    On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson
    <> wrote or quoted :

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

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




    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 20, 2005
    #9
  10. Roedy Green wrote:

    > On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson
    > <> wrote or quoted :
    >
    >
    >>>Just to clarify, it is a console application - all input and output is
    >>>done on the console.

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


    (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. )
     
    Andrew Thompson, Oct 20, 2005
    #10
  11. Roedy Green Guest

    On 20 Oct 2005 08:51:12 +0200, Gordon Beaton <> wrote or
    quoted :

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

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 20, 2005
    #11
  12. On Thu, 20 Oct 2005 08:33:00 GMT, Roedy Green wrote:
    > 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

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Oct 20, 2005
    #12
  13. wrote:
    > 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
    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
     
    Thomas Weidenfeller, Oct 20, 2005
    #13
  14. Roedy Green Guest

    On Thu, 20 Oct 2005 08:32:41 GMT, Andrew Thompson
    <> wrote or quoted :

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


    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 20, 2005
    #14
  15. Roedy Green Guest

    On 20 Oct 2005 11:27:00 +0200, Gordon Beaton <> wrote or
    quoted :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Oct 20, 2005
    #15
  16. On Thu, 20 Oct 2005 11:18:35 GMT, Roedy Green wrote:
    > 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

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Oct 20, 2005
    #16
  17. John Currier Guest

    Roedy Green wrote:
    > On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson
    > <> wrote or quoted :
    >
    > >> Just to clarify, it is a console application - all input and output is
    > >> done on the console.

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


    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
     
    John Currier, Oct 20, 2005
    #17
  18. zero Guest

    Andrew Thompson <> wrote in news:JCI5f.23130
    $:

    > Roedy Green wrote:
    >
    >> On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson
    >> <> wrote or quoted :
    >>
    >>
    >>>>Just to clarify, it is a console application - all input and output is
    >>>>done on the console.
    >>>
    >>>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.

    >
    > (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.
     
    zero, Oct 20, 2005
    #18
  19. zero wrote:
    > Andrew Thompson <> wrote
    >>Roedy Green wrote:
    >>>On Thu, 20 Oct 2005 04:36:22 GMT, Andrew Thompson wrote:
    >>>
    >>>>>Just to clarify, it is a console application - all input and output is
    >>>>>done on the console.
    >>>>
    >>>>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.

    >>
    >>(shrugs) ..and what? It takes but a moment,

    ....
    > 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, Oct 20, 2005
    #19
  20. Roedy Green wrote:

    > On Thu, 20 Oct 2005 08:32:41 GMT, Andrew Thompson
    > <> wrote or quoted :
    >
    >>( 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 ..


    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..>
     
    Andrew Thompson, Oct 20, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lucas Cowald
    Replies:
    4
    Views:
    1,081
    Tohid
    Oct 23, 2003
  2. AAaron123
    Replies:
    2
    Views:
    2,202
    AAaron123
    Jan 16, 2009
  3. AAaron123
    Replies:
    1
    Views:
    1,357
    Oriane
    Jan 16, 2009
  4. Marcin Tyman

    Conversion mask in hex to bit mask

    Marcin Tyman, May 6, 2008, in forum: Ruby
    Replies:
    4
    Views:
    826
    Robert Klemme
    May 6, 2008
  5. 187
    Replies:
    2
    Views:
    566
    Bart Lateur
    Jul 29, 2004
Loading...

Share This Page