This question already has answers here:
Golang reading from stdin, how to detect special keys (enter, backspace... etc)
(1 answer)
How to catch keypress without enter in Golang loop
(2 answers)
Closed 28 days ago.
I developed a little application, that serves through TCP socket; all works fine, but I'd like to do a step more: is it possible to catch special keys (like UP arrow, DOWN arrow, Fx function, ecc.) through a socket?
Related
This question already has answers here:
Is it necessary to close files after reading (only) in any programming language?
(3 answers)
Does the file need to be closed?
(1 answer)
Closed 2 years ago.
It seems that os.Open() open read-only files. So I think there is no need to Close() it. The doc is not clear on this. Is my understanding correct?
https://golang.org/pkg/os/#Open
In general, you should always close the files you open. In a long running program, you may exhaust all available file handles if you do not close your files. That said, the Go garbage collector closes open files, so depending on your exact situation leaving files open may not be a big deal.
There is a limit to how many filehandles a process can have open at once, the limit is determined by your environment, so it's important to close them.
In addition, Windows file locking is complicated; if you hold a file open it may not be able to be written to or deleted.
Unless you're returning the open filehandle, I'd advise to always match an open with a defer file.Close()
Close releases resources that are independent of the read/write status of the file. Close the file when you are done with it.
Your best bet is to always use defer file.Close(). This function is invoked for cleanup purposes, and also releases resources that are indirectly related to the I/O operation itself.
This also holds true to HTTP/s response bodies and any data type that implements the Reader interface.
This question already has answers here:
Passing arguments to an interactive program non-interactively
(5 answers)
Closed 2 years ago.
I need to write a bash script that runs some console application with arguments, lets say app.exe -arg. The problem is, that program while it's working, asks user to press some key e.g. press o for OK or c for Cancel. I need to scan output at all times for such expressions and press certain keys when needed. Ideally I would have a set of rules that whould apply to the whole output for the whole time, and when expression 1 is found, do this, when expression 2 is found in output, do that (like press some key) and allow output to be examined further the same fassion. Until some "ending expression" is found, then close script. Im kinda newbie in bash scripting. Any help?
expect is the answer to your question. It allows you to automate such procedures:
wait for a certain phrase
provide input
...
Can someone help me understand why pw (the writer) is scheduled for closing in Start()?
I would expect pw to be closed together with pr ( the reader) in Wait().
closeAfterStart and closeAfterwait are two slices of io.Closers which are called respectively ins Start and Wait of cmd Struct. Now, why is this? both these are basically buffers(slices) which either need to be written into read off of. Depending on whether they are currently in use, they are closed. for example StdInPipe requires reading first and then writing to, therefore the pr is included in closeAfterStart and pw in closeAfterWait. The reverse is done for StdOutPipe.
The program is simply closing off the buffers which it doesn't need anymore in the code. In StdErrPipe the function is called after execution of command, to write the error output to some output. So, the program already has the output it needs to write.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
This weekend, there was a CTF wargame happening, Secuinside CTF 2013 ( http://war.secuinside.com/ )
Being a computer security enthousiast, I took a look at the challenges, and at their solutions after the CTF was over.
One of the challenges was about getting a remote shell on a server, given that a daemon called "givemeshell" is running on this server. What the daemon does is keeping a socket open on a chosen port, let's say port 12345.
When the socket receives something, the daemon takes the first 5 chars and launch them in a shell.
For example, if I send cat file, the daemon will launch the command cat f in a shell. No response is sent, so I can't know the result of the command.
The objective is to read a file containing the flag.
Now, someone gave me this solution :
$ nc 1.2.3.4 12345
4<>a
$ nc 1.2.3.4 12345
sh<&4
sh>&4
cat flag
The flag is _FLAG_
I tested this solution and it works. But after spending several hours trying to understand it, I still can't figure out what it does and why it works. I understand this is about redirecting something...
Can someone explain it to me? Thanks!
4 is your connection's file descriptor.
0 is the program stdin, 1 is the program stdout, 2 is the program stderr, when you created a socket to listen for connections it was then assigned to 3, and when it accepted your connection, a new file descriptor of number 4 was created to handle this connection.
4 is the ID of the file descriptor of your connection to the backdoor, assuming you are the first one to connect.
You then type sh<&4. It opens sh and tell it should get all input directly from your connection.
Right now you are already in full control of the shell, because sh took over and every command you send is interpreted directly by it. But you still cannot see any output!
Then you type sh>&4 to open a new level of sh inside the other saying it should push all output to your file descriptor. The trick is done! Two-way communication.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 11 months ago.
Improve this question
I've written shell scripts using escape codes to move the cursor and change the color. There are however escape codes that return a response.
I'm struggling to figure out how one reads the responses to control codes that query the terminal itself, particularly within a shell script? Codes like <ESC>[6n which is "Query Cursor Position"
It doesn't seem to be standard out or standard error as far as I can tell. I am confused.
In ZSH I do the following
~ » echo "\e[6n"
~ » 3;1R
the response to the query comes through as the next Terminal command, already typed in for me. I don't understand how. I also am unclear why bash doesn't seem to demonstrate this behavior.
What do I read this value from?
The responses come through on the channel from the terminal (or terminal emulator) to the serial port (or other tty device). That's the same channel used for transmitting characters entered at the terminal keyboard; there is no out-of-band signaling.
Since you didn't read the response after sending the query, it was interpreted as a series of keypresses by your shell. The different shells have different responses to the unusual keyboard input.
To read the response properly, you have to take the terminal out of line-based ("icanon" or "cooked") mode and read a byte at a time (from the tty, i.e. possibly stdin, the same place you'd read keyboard input from) until the terminating character is found. And there's no real way to distinguish the response from any real keypresses that happened to occur at the same time.
It's an unclean business, and if you're trying to do it in a shell script you add extra pain.