2
public static void main(String[] args){
    System.out.println("enter password");
    char[] password = System.console.readPassword();
    if(passwordOK(password)){
        //let go of shell, and continue running.
    }
}

I want the Java application to keep on running, but stop "hogging" the cmd/terminal. Release cmd/terminal so that I can use it as per normal, while the application continues to run. No more terminal usage after password auth/setup.

theAnonymous
  • 1,701
  • 2
  • 28
  • 62
  • 1
    I can't think of any terminal-based app that releases the terminal once it's done entering one piece of information. The convention I've seen is that it keeps the terminal until the *entire* application is done running. – Makoto Sep 12 '17 at 14:54
  • Maybe this could help you: https://stackoverflow.com/questions/636367/executing-a-java-application-in-a-separate-process – Robertiano Sep 12 '17 at 14:58
  • 1
    This sounds like an [XY problem](https://meta.stackexchange.com/a/66378/286538). Please tell us what makes you try to design a program like that. What is your real task? What do you do with the terminal while the program is running? – RealSkeptic Sep 12 '17 at 14:58
  • @RealSkeptic for example, a SSL server that wants user input to decrypt a password-encrypted private key, then continues as a daemon. – slim Sep 12 '17 at 15:00
  • Is an OS-specific solution acceptable? Which OS? – slim Sep 12 '17 at 15:02
  • Sorry, it should work with Windows (priority) and Linux, but if you have ANY available, I'll look into it. – theAnonymous Sep 12 '17 at 15:02
  • Exactly as what slim said. I need it to take in user input for auth purposes, and release it without having a terminal that somebody can close without knowing what he/she is doing. – theAnonymous Sep 12 '17 at 15:03
  • How about taking the user input in a shell script, rather than inside Java? You'll then be able to run the Java program in the background or in a separate service or whatever. – RealSkeptic Sep 12 '17 at 15:04
  • Passing in args will cause them to show up when checking what apps are running. – theAnonymous Sep 12 '17 at 15:05
  • Well, you can save the argument in file. You could encrypt it. You could also split the application into two stages - stage one does the above, and exits with status 0 if the password was OK, and with a status 1 if it wasn't. And then you run the second part in the background only if the first part succeeded. – RealSkeptic Sep 12 '17 at 15:09
  • Does it have to be a *terminal*? Why not just a Swing or JavaFX dialog box? – Klitos Kyriacou Sep 12 '17 at 15:29
  • 1
    @KlitosKyriacou I dunno about OP, but it really annoys me if I can't launch a server over a remote terminal. – slim Sep 12 '17 at 15:33

1 Answers1

2

I don't think a running process can switch itself from foreground to background, detaching from its input and output. A suitably sophisticated shell can, of course, use job management to background running tasks (in most UNIX shells, ctrl-Z, fg, bg etc.).

In Java the best I can think of is to write two programs:

  • your long-running server runs in the background, and starts by opening a ServerSocket, it listens for one connection, on which it expects to receive the authentication info. Only when that has happened does it initialise fully and go into its main listening loop.
  • another program runs in the foreground. It waits for the socket to become available, connects, prompts at the terminal for a password, writes that to the socket, closes and terminates

You'll need to do some simple scripting to launch both programs at the same time. There's no reason why both programs have to be Java -- on UNIX I'd be tempted to use netcat to squirt the password into the server.

For security, ensure that the socket uses localhost networking. On UNIX it could instead be a UNIX domain socket.

Of course there are lots of communication methods your two processes could use -- files, shared memory, pipes, TCP sockets, ... -- it's a matter of picking one that's secure enough for the information you're passing between them.

slim
  • 40,215
  • 13
  • 94
  • 127