I am experiencing an issue with my program where when I hit a certain menu I am unable to enter in an option. The menu looks like a prompt with a pre-selected option where one is able to change the option by over writing it.
Here is what it looks like:
As you can see 3 is already selected. I simply want to over write it and enter in another option.
When I simply try to write an option to it and print out what the shell it it gives me this when I do a system.out.println:
set encryption home
Wireless Encryption Type:[0] quit, [1] OPEN, [2] WEP, or [3] WPA
Wireless Encryption Type: 31
It will simply do option 3 and ignor the "1" and will read the "\r\n" I have in the command I sent (which was "1\r\n"). In between there is a character which is not represented here it is character 0x08. How can I get my program to overwrite the default option?
Things I have tried:
I have tried doing \n\r
semicolon ;
\n\r before the command
\r
ommiting \r\n (this causes the program to never go past the wireless encryption type because it did not enter anything).
I have no idea what to do next with this. Any ideas?
ps: I am using a pipedinput to enter in all of the commands as suggested by nilbot
found the problem, the shell did not like the /n/r and counted each one as an enter. so it works once i removed either the /r or the /n. currently I have it at /n, hope this helps someone!
Related
I've been looking into a way to implement a "Press any key to continue" feature into my program, and figured I'd use $stdin.getch.
Seems to work in most cases, but I noticed that if I pressed an arrow key when prompted to press any key, the next gets command would have "parasites" characters at the beginning of the string it returned, presumably because arrow keys give several characters as input and only the first one is read by getch, with the rest being saved for the next gets. More precisely, when I press the Right Arrow key, getch returns "\e" and the next gets return has a "[C" prefixed to it.
I thought maybe I had to flush/empty the stdin buffer, but flush, iflush and ioflush don't seem to do anything. Trying to write '' into stdin before the gets doesn't work either. I've also tried sync and fsync on $stdin, but it doesn't work either. Any idea what the problem could be?
getch puts the IO in so-called raw mode and then reads a single character.
However, there are keys that generate more than one character when being pressed. The right arrow key → for example is usually configured to generate the 3-byte sequence \e[C which is the ANSI escape sequence for "cursor forward".
Now, if you attempt to read that sequence via getch, you'll only get \e, i.e. the very first character. All subsequent characters (here: [ and C) will be returned by the next read operation.
Instead of reading a single character via getch, you could put stdin into raw mode manually and read all available characters (up to a reasonable limit) via readpartial, e.g.:
$stdin.raw { |io| io.readpartial(100) }
The above returns the whole "\e[C" sequence when pressing → and behaves like getch for single-character keys.
Note that terminal emulators and operating systems behave differently. The above works just fine for me, but you might want to test the solution on various systems yourself.
I came across some code for chat application in the terminal (in OCaml) and swa this string (in ASCII?) "\r\027[1A\027[K" being printed into the terminal before a new user message is printed to the terminal.
I have tried googling literals one by one, so I know that "\r" stands for cartridge return and \027 for ESC in ASCII, but what does "[1A" and "[K" do? What character encoding is this?
And finally, what is the aggregate effect of this command?
[ introduces a control sequence. A is the control sequence for "cursor up", and [1A moves the cursor up 1 line. K erases a line. So \x1b[1A\x1b[K moves up one line and deletes it (replaces it with spaces).
Of course, that is only valid if the terminal that receives that string recognizes the control sequences. Not all do.
See https://en.wikipedia.org/wiki/ANSI_escape_code
I'm not sure what 027 is trying to do. It seems like an error and should have been 033.
I would like to improve the help facility in a Fortran program by opening the user guide in a separate browser (Firefox) window whenever the user type a ?
as answer to a question the program asks.
I can use call system('path/firefox -file user_guide.hlp')
to open the help file. But additionally I would like to position the text in the browser window at a specified line in the help text.
I know which lines in the help file that should be relevant for the user because inside the Fortran program I keep track of the commands the user has made (I use a command line interface, no GUI). At present I print these lines in the terminal window running the program but this limits the amount of lines I can print and obscures the program output. With the whole user guide available in a separate window the user may also easily search for additional explanations elsewhere in the user guide, I do not expect he or she will voluntarily read the user guide.
Thanks for any help
Bo Sundman
You cannot go to specific lines but you could try using named anchor tabs. In the help file,
<a name="1"/>
help topic 1
<a name="2"/>
help topic 2
When you issue your call to firefox, to go to anchor 2
system('path/firefox -file user_guide.html#2')
This should work on all browsers. The newer ones will also take id= instead of name=
EDIT
If the above doesn't work, try
system('path/firefox "file://path/user_guide.html#2"')
EDIT 2
If both the firefox path and html file path have spaces, on Windows, 8.3 filenames can be used. Use dir/x to find out what the 8.3 filenames are. Alternatively filenames with spaces can be used; the syntax is pretty weird
call execute_command_line('""C:\...\firefox.exe" "file://x:\...\userguide.html#2""')
start string with '
Use 2 double quotes for the first double quote ""
Add your pathname to firefox
Use 1 double quote to terminate the path name
add a space
Use 1 double quote to start the parameter
Add the parameter
Use 2 double quotes to terminate
end the string with '
At the moment, I have a process-buffer which is utf-8-auto (emacs modeline reports the buffer as utf-8-auto-dos) with CRLF style newlines. When I write multi-line text into the buffer via a process-send-region or process-send-string each line is suffixed with ^M.
What makes this problem odd is that text written to the process-buffer directly from the process, does not contain ^M's.
It doesn't seem to make any difference where the source text comes from, in fact, even a multi-line region marked and sent that already appears in the process buffer (that doesn't contain ^M) will have them when sent.
(Note the source text for the process-send-region will always come from a Emacs buffer, process-send-string, when multi-line will be from the Windows clipboard interface to the killring, or again from an Emacs buffer to killring.)
I should also add that the incoming text to the buffer is parsed by a after-change-functions hook (to do some colorisation based on input) so a last resort I'd do an additional regexp-replace-in-string on this incoming text as part of that hook function, I'd like to avoid that because it seems wrong, but I'll add it as a hacky solution if nothing else works.
Addendum
I updated the encoding settings for the buffer and the process to use utf-8-dos instead of utf-8-auto and the ^M's vanished.
So in the buffer setup part of my app, I did...
(switch-to-buffer "sock-buffer")
(set-process-coding-system (get-process sock-process) 'utf-8-dos 'utf-8-dos)
(set-buffer-file-coding-system 'utf-8-dos nil)
(set-buffer-process-coding-system 'utf-8-dos 'utf-8-dos)
Then reduced this to just...
(switch-to-buffer "sock-buffer")
(set-buffer-process-coding-system 'utf-8-dos 'utf-8-dos)
And everything worked fine.
This is because those files are in DOS/Windows line endings. You can use C-x [Enter] f unix [Enter] to convert them to the Unix encoding.
^L is a page break. I've seen them some times to separate different parts of source code (for old-fashioned listings in a text printer), or in text documentation to insert an actual "new page" command.
As of the update, here you can see that you have to select set-process-coding-system to the correct coding system.
Alternately to the dos2unix approach, you could use one of the MULE commands in Emacs, or (my favorite), since these characters are mistakenly treated as part of the text, you can replace them using the command to replace a string in the text: M-% C-q C-M RETURN
M-% is the query-replace command.
C-q means "let me type the next character without interpreting it as the RETURN key".
I believe you see those because of the inconsistencies in your newlines (e.g. windows newlines vs *nux ones), you should probably try dos2unix
I recently made the insanely long overdue switch from tcsh to bash.
The only thing I miss is tcsh's ESC+p feature:
Start typing a command and then hit ESC+p (I actually found the equivalent ctrl-[p easier to type) and it jumps to the most recent command in your history that starts with what you've typed so far.
Perhaps the best answer is to just get used to bash's Ctrl+r but so far I don't like it as much.
I often start typing a command and then it occurs to me that I've issued it before.
With tcsh's feature I could then do ESC+p+Enter to re-issue it. It's so quick that I'd usually never use up-arrow for anything more than 2 commands ago.
An example of where I found it especially nice:
Long commands often start with a dot, because they're of the form
./myprogram.pl -lots -of -args -and -switches
In tcsh I would issue a command like that, then maybe ls, less, tail, whatever, and then to reissue the long command, 4 keys: dot, escape, p, enter.
How can I do that in Bash? Or, to make it concrete, what's the fewest number of keystrokes in bash to say "repeat the last command that started with a dot"? Can it match or beat tcsh's 4?
I was in the same boat as you, needing to switch to bash from tcsh.
I just created a new ~/.inputrc file as follows and everything works great!
$ cat ~/.inputrc
"\ep": history-search-backward
"\en": history-search-forward
Add this to your ~/.inputrc file:
"\e[5~": history-search-backward
"\e[6~": history-search-forward
This will make PageUp act like tcsh's Esc+p and PageDown will go forward through the list.
You can bind \ep instead. If you use PageUp / PageDown, you may need to see what character sequence your keyboard/terminal produces. Just press Ctrl+V then PageUp and you'll see ^[[5~ if it's the same as \e[5~.
Personally I prefer ctrl-r - it's interactive search through history - check it, perhaps you'll like it. Subsequent ctrl-r presses jump to next match.
Well, you can do
!.
Which is three characters (including the Enter). Of course, in the general case, you can replace the dot with the unique identifying prefix of your choice.