How to set carriage return location or equivalent? - linux

I am looking for a way to set where the carriage return, returns to or an equivalent way to do so.
For example I have a line like this:
^ denotes cursor location
myshell>cat file.txt
^
After carriage return it should look like this.
myshell>cat file.txt
^

You're probably after what's collectively called ANSI escape sequences. Its hard to search for if you really have no idea what you're after.
This tiny example saves/restores cursor position:
#include <stdio.h>
int main(int argc, char**argv)
{
char cmd_buf[100];
cmd_buf[0]=0;
while(strncmp(cmd_buf, "quit", 4))
{
printf("mypromt>\033[s <-Cursor should go there\033[u");
fflush(stdout);
fgets(cmd_buf, sizeof(cmd_buf), stdin);
printf("\nYou entered: %s\n", cmd_buf);
}
}
Note that in terminator, gnome-terminal and xterm on Ubuntu, this "magically" supports CTRL+U as-is, but not CTRL+A or CTRL+E.
There are many, many more sequences available. The wikipedia page is probably the simplest reference to get you started.
Update: Also, unless you're doing this as a learning exercise (which I get the impression Benjamin is), to build an interactive shell, you should probably use one of the two well established libraries for shell-style line editing, namely:
readline (GPLv3, but far more popular)
editline (BSD licensed, closest "second place")
They are the libraries that provide the emacs-style (typical default) and vi-style keybindings and history features we all know and love from bash, python, lua, perl, node, etc, etc.

For positioning on the screen, termios is of limited use (the ioctl's dealing with screensize are not in POSIX), and unless you want to assume a lot about the terminal characteristics, control characters and escape sequences have their limitations.
You can do what's asked in curses using the filter function to tell the library you want to use just the current line of the display. As written, the question is puzzling since it does not mention any output other than the current line. But for example (this is exactly what was asked):
#include <curses.h>
int
main(void)
{
int ch, y, x;
filter();
initscr();
cbreak();
addstr("myshell>");
getyx(stdscr, y, x);
while ((ch = getch()) != ERR) {
if (ch == '\n')
move(y, x);
}
endwin();
return 0;
}
However, a usable program would do more than that. There's an example of the filter() function in ncurses-examples, which you may find useful for reading. A screenshot:

Related

How to display a box drawing character using the ncurses crate?

I'm writing an app using Rust and ncurses.
I'm trying to display a box drawing character ('┃' (Unicode 9475 / 0x2503)), but it's as if it's not even printed to screen. When I select the text, it can be seen:
Here's a minimal example:
use ncurses::*;
fn populate_line_numbers() {
for i in 0..LINES() {
mvaddstr(i, 0, &i.to_string());
}
mvvline(0, 4, 9475, LINES());
refresh();
}
fn main() {
setlocale(LcCategory::all, "");
initscr();
start_color();
keypad(stdscr(), true);
noecho();
loop {
let user_input = get_wch();
match user_input.unwrap() {
WchResult::Char(ch) => {
match ch {
27 => break,
_ => {
addstr(&std::char::from_u32(ch).unwrap().to_string());
refresh();
}
}
},
WchResult::KeyCode(code) => {
match code {
KEY_F5 => {
populate_line_numbers();
},
_ => {}
}
}
}
}
endwin();
}
Hit F5 to make the program show line numbers.
How can the character be like the normal text? I tried to OR it together with a bunch of things, but nothing worked out.
Cargo.toml
[dependencies]
ncurses = { version = "5.99.0", features = ["wide"] }
Author's note: The following is a best-effort analysis based mostly on examining ncurses.h on my system and comparing it to the source code of ncurses-rs. I may be wrong in some particulars.
In ncurses, the chtype type alias (which is the third argument of mvvline) represents a single-byte character plus some appearance metadata. It cannot store a multibyte character. So mvvline simply cannot display ┃.
(Presumably the reason you get an invisible line is because the value 9475 represents a control character with some bogus appearance information. I wasn't able to figure out how to decode it. If you fiddle around with the byte values I'm sure you can get the line to change colors and contain any ASCII character you want.)
To draw a line using a "wide" (multibyte) character, you must link to a version of ncurses with wide character support, and use the wide character version of mvvline, which appears to be called mvvline_set. This function takes a const cchar_t * argument instead of chtype, where cchar_t is a struct containing a multibyte character plus some metadata.
Unfortunately, although the ncurses crate does link to the correct version of the ncurses library, it does not expose any way to call mvvline_set. There are a number of other functions that are also missing from the ncurses-rs API, mostly the ones that use the cchar_t struct. This means you won't be able to use Unicode line-drawing characters in character-oriented ncurses functions, unless you write the bindings yourself.
You should still be able to use multibyte characters in UTF-8 strings and pass them to string-oriented functions such as mvaddstr.

proper way of catching control+key in ncurses

What is the proper way of catching a control+key in ncurses?
current im doing it defining control like this:
#define ctl(x) ((x) & 0x1f)
it works ok, but the problem is that i cannot catch C-j and ENTER at the same time, and this is because:
j = 106 = 1101010
0x1f = 31 = 0011111
1101010 & 0011111 = 0001010 = 10 = ENTER key..
So.. how shall I catch it?
Thanks!
--
Edit:
If i try the code below,
I am not able to catch the enter key correctly, not even in the numeric keyboard. Enter gets catched as ctrl-j.
#include <stdio.h>
#include <ncurses.h>
#define ctrl(x) ((x) & 0x1f)
int main(void) {
initscr();
int c = getch();
nonl();
switch (c) {
case KEY_ENTER:
printw("key: %c", c);
break;
case ctrl('j'):
printw("key: ctrl j");
break;
}
getch();
endwin();
return;
}
New code:
#include <stdio.h>
#include <ncurses.h>
#define ctrl(x) ((x) & 0x1f)
int main(void) {
initscr();
int l = -1;
int c = getch();
cbreak();
noecho();
nonl();
keypad(stdscr, TRUE);
switch (c) {
case KEY_ENTER:
printw("key: %c", c);
break;
case ctrl('j'):
printw("key: ctrl j");
break;
}
printw("\nnow press a key to end");
getch();
endwin();
return;
}
Try nonl:
The nl and nonl routines control whether the underlying display device
translates the return key into newline on input, and whether it translates newline into return and line-feed on output (in either case, the
call addch('\n') does the equivalent of return and line feed on the
virtual screen). Initially, these translations do occur. If you disable them using nonl, curses will be able to make better use of the
line-feed capability, resulting in faster cursor motion. Also, curses
will then be able to detect the return key.
Further reading: the Notes section of the getch manual page:
Generally, KEY_ENTER denotes the character(s) sent by the Enter key on
the numeric keypad:
the terminal description lists the most useful keys,
the Enter key on the regular keyboard is already handled by the
standard ASCII characters for carriage-return and line-feed,
depending on whether nl or nonl was called, pressing "Enter" on the
regular keyboard may return either a carriage-return or line-feed,
and finally
"Enter or send" is the standard description for this key.
That addresses the question about newline/carriage-return translation. A followup comment is a reminder to point out that the manual page gives basic advice in the Initialization section:
To get character-at-a-time input without echoing (most interactive,
screen oriented programs want this), the following sequence should be
used:
initscr(); cbreak(); noecho();
and that OP's sample program did not use cbreak (or raw). The manual page for cbreak says
Normally, the tty driver buffers typed characters until a newline or
carriage return is typed. The cbreak routine disables line buffering
and erase/kill character-processing (interrupt and flow control characters are unaffected), making characters typed by the user immediately
available to the program. The nocbreak routine returns the terminal to
normal (cooked) mode.
Initially the terminal may or may not be in cbreak mode, as the mode is
inherited; therefore, a program should call cbreak or nocbreak explicitly. Most interactive programs using curses set the cbreak mode.
Note that cbreak overrides raw. (See curs_getch(3x) for a discussion
of how these routines interact with echo and noecho.)
Also, in curs_getch you may read
If keypad is TRUE, and a function key is pressed, the token for that
function key is returned instead of the raw characters:
The predefined function keys are listed in <curses.h> as macros
with values outside the range of 8-bit characters. Their names begin with KEY_.
That is, curses will only return KEY_ENTER if the program calls keypad:
keypad(stdscr, TRUE);
For the sake of discussion, here is an example fixing some of the problems with your sample program as of May 17:
#include <stdio.h>
#include <ncurses.h>
#define ctrl(x) ((x) & 0x1f)
int
main(void)
{
int c;
initscr();
keypad(stdscr, TRUE);
cbreak();
noecho();
nonl();
c = getch();
switch (c) {
case KEY_ENTER:
printw("\nkey_enter: %d", c);
break;
case ctrl('j'):
printw("\nkey: ctrl j");
break;
default:
printw("\nkeyname: %d = %s\n", c, keyname(c));
break;
}
printw("\nnow press a key to end");
getch();
endwin();
return 0;
}
That is, you have to call keypad before getch, and the value returned for KEY_ENTER is not a character (it cannot be printed with %c).
Running on the Linux console with the usual terminal description, you will see only carriage return for the numeric keypad Enter, because that description does not use application mode. Linux console does support application mode, and a corresponding description could be written. As a quick check (there are differences...) you could set TERM=vt100 to see the KEY_ENTER.

Escape substituted path in SCons

In this piece of code from Wesnoth build the $TESTFILE variable is substituted with the given path. But on Windows path becomes invalid, because by default SCons subst() doesn't escape backslashes in paths. Is there a way to do this - get absolute filename for SCons File node with escaped backslashes? Or escape backslashes while substituting?
test_program = '''
#include <SDL_mixer.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
Mix_Music* music = Mix_LoadMUS("$TESTFILE");
if (music == NULL) {
exit(1);
}
exit(0);
}
\n
'''
print Environment(TESTFILE = File("data/core/music/main_menu.ogg").rfile().abspath). \
subst(test_program)
The output:
#include <SDL_mixer.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
Mix_Music* music = Mix_LoadMUS("E:\wesnoth\scons\data\core\music\main_menu.ogg");
if (music == NULL) {
exit(1);
}
exit(0);
}
How about os.path.normpath from python 2.7 docs..?
os.path.normpath(path)
Normalize a pathname by collapsing redundant
separators and up-level references so that A//B, A/B/, A/./B and
A/foo/../B all become A/B. This string manipulation may change the
meaning of a path that contains symbolic links. On Windows, it
converts forward slashes to backward slashes. To normalize case, use
normcase().
After cloning the Wesnoth repo and inspecting the actual build files, I found that the problem you describe happens in the context of configuration. This doesn't get clear in your original question, and renders my first try of an answer useless (using the Substfile builder, see history).
As far as I know, there is currently no option built into SCons to handle the double-backslashing you're looking for. The cleanest way I can think of right now would be to clone the method SConf.SConfBase.TryRun (e.g. name it TryRunWithArgs), make it accept additional program arguments, add it to the configure context with AddTest() and then rewrite the test program such that it accepts the filename as first argument.

Segmentation fault while trying to print parts of a pointer struct

I'm writing a program that must take user input to assign values to parts of a structure. I need to create a pointer to the structure that I will pass through as a one and only parameter for a function that will print each part of the structure individually. I also must malloc memory for the structure. As it is now, the program compiles and runs through main and asks the user for inputs. A segmentation fault occurs after the last user input is collected and when I'm assuming the call to the printContents function is run. Any help would be appreciated!
#include <stdio.h>
#include <stdlib.h>
struct info
{
char name[100], type;
int size;
long int stamp;
};
void printContents(struct info *iptr);
int main(void)
{
struct info *ptr=malloc(sizeof(struct info));
printf("Enter the type: \n");
scanf("%c", &(*ptr).type);
printf("Enter the filename: \n");
scanf("%s", (*ptr).name);
printf("Enter the access time: \n");
scanf("%d", &(*ptr).stamp);
printf("Enter the size: \n");
scanf("%d", &(*ptr).size);
printf("%c", (*ptr).type);
printContents(ptr);
}
void printContents(struct info *iptr)
{
printf("Filename %s Size %d Type[%s] Accessed # %d \n", (*iptr).name, (*iptr).size, (*iptr).type, (*iptr).stamp);
}
Check the operator precedence. Is this &(*ptr).type the thing you're trying to do? Maybe &((*ptr).type) ?
ptr->member is like access to structure variable right? Also same for scanf() usr &ptr->member to get value. For char input use only ptr->charmember .
First let's do it the hard way. We'll assume that the code is already written, the compiler tells us nothing useful, and we don't have a debugger. First we put in some diagnostic output statements, and we discover that the crash happens in printContents:
printf("testing four\n"); /* we see this, so the program gets this far */
printf("Filename %s Size %d Type[%s] Accessed # %d \n", (*iptr).name, (*iptr).size, (*iptr).type, (*iptr).stamp);
printf("testing five\n"); /* the program crashes before this */
If we still can't see the bug, we narrow the problem down by preparing a minimal compete example. (This is a very valuable skill.) We compile and run the code over and over, commenting things out. When we comment something out and the code still segfaults, we remove it entirely; but if commenting it out makes the problem go away, we put it back in. Eventually we get down to a minimal case:
#include <stdio.h>
int main(void)
{
char type;
type = 'a';
printf("Type[%s]\n", type);
}
Now it should be obvious: when we printf("%s", x) something, printf expects x to be a string. That is, x should be a pointer to (i.e. the address of) the first element of a character array which ends with a null character. Instead we've given it a character (in this case 'a'), which it interprets as a number (in this case 97), and it tries to go to that address in memory and start reading; we're lucky to get nothing worse than a segfault. The fix is easy: decide whether type should be a char or a char[], if it's char then change the printf statement to "%c", if it's char[] then change its declaration.
Now an easy way. If we're using a good compiler like gcc, it will warn us that we're doing something fishy:
gcc foo.c -o foo
foo.c:35: warning: format ‘%s’ expects type ‘char *’, but argument 4 has type ‘int’
In future, there's a way you can save yourself all this trouble. Instead of writing a lot of code, getting a mysterious bug and backtracking, you can write in small increments. If you had added one term to that printf statement at a time, you would have seen exactly when the bug appeared, and which term was to blame.
Remember: start small and simple, add complexity a little at a time, test at every step, and never add to code that doesn't work.

Entering text in snippet fields uses wrong character when using langmap

I am using a custom keymap using langmap option in vimrc.
I am trying to use snipmate but I am running into trouble. When I type a word and hit tab it allows me to edit the parameter. The problem is that the first character is the remapped one, while I want it to be the actual key.
For instance, I'll type this:
for
and hit tab to expand the snippet:
for (i = 0; i < COUNT; ++i)
The i is highlighted which means I can edit it. I type "aaa":
for (baa = 0; i < COUNT; ++i)
It comes out baa even though I typed aaa. This is because I remapped a and b.
How can I fix this?
Here is my keymapping:
set langmap=nj,N},ek,E{,il,IL,{^,}$,lb,LB,uw,UW,ye,YE,jg,JG,\\;z,f\\.,F\\,,zu,ZU,.?,\\,/,/v,? V,ta,TA,si,SI,ro,RO,ac,AC,wr,WR,xx,XX,dd,DD,bs,BS,gf,GF,pt,PT,kn,KN,cy,CY,vp,VP,o\\;
It won't make much sense to others, and I haven't finalized how I want it to look.
From your :set langmap I understand that you mapped a to c so, by typing aaa, did you expect to obtain ccc?
From what I understand (:help langmap), your custom substitutions are not available in INSERT mode for actually inserting stuff and I don't see a mention of the SELECT mode you are in when overwriting SnipMate's placeholders.
If I do this
:set langmap+=ac,bs
and I type aaa in SELECT mode, I obtain caa.
That's because langmap applies to the first a (:help Select-mode) and, therefore inserts c. But, after this first character I am in INSERT mode for all subsequent characters. Since langmap doesn't apply in INSERT mode, aa is inserted as is.
What is not clear to me is why you obtain baa instead of caa. Your langmap seems to be pretty clear about your intention: you want a to insert c and b to insert s. Typing a shouldn't insert b.
I smell a risk of mistyping in your .vimrc. Try this: reset your set langmap and start adding your mappings one by one.
May I ask you what is the purpose of such a massive remapping?
C program which outputs mappings similar behavior to langmap but not for select:
/* input:
lhs rhs optional-descripton
lhs rhs ...
*/
#include <stdlib.h>
#include <stdio.h>
int main() {
FILE *fi = fopen("in.txt", "r");
FILE *fo = fopen("out.txt", "w");
char lc[8], rc[8];
while (fscanf(fi, "\n%s %s", lc, rc) != EOF) {
fprintf(fo, "nnoremap %s %s\n", lc, rc);
fprintf(fo, "xnoremap %s %s\n", lc, rc);
fprintf(fo, "onoremap %s %s\n", lc, rc);
while (fgetc(fi) != '\n');
}
fclose(fo);
fclose(fi);
}
It doesn't work identically to langmap and so it might break other bindings.
This has now been fixed in vim 7.4.1150. See
https://github.com/vim/vim/issues/572
for details.

Resources