Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

color ydb_prompt #348

Closed
pkoper opened this issue Dec 12, 2018 · 2 comments
Closed

color ydb_prompt #348

pkoper opened this issue Dec 12, 2018 · 2 comments

Comments

@pkoper
Copy link

pkoper commented Dec 12, 2018

GT.M allows ANSI escape codes in gtm_prompt which are very useful for having dev prompts in green, production prompts in red, test prompts in yellow and so on:

image

Looks like support for ANSI escape codes in YottaDB's ydb script is broken for gtm_prompt environment variable and not allowed for ydb_prompt environment variable:

image

When mumps -direct is used:

image

The expected result is to have printed to the terminal any binary content of gtm_prompt or ydb_prompt in the same way as PS1 environment variable in Bash (or gtm_prompt in GT.M).

@pkoper
Copy link
Author

pkoper commented Dec 12, 2018

gtmprofile from GT.M expands escape sequences in "\e[1;32mDEV\e[m GTM>" into binary form and gtmprofile form YottaDB does not. It's ok, one can put into ydb_prompt already expanded escape sequences using "echo -e".

YottaDB mumps binary is ok, looks like the problem is with the ydb script (please mind the -e switch for echo):

image

Narrowing problem even more it is something with shell expansion:

image

@nars1
Copy link
Collaborator

nars1 commented Dec 12, 2018

This issue is already fixed, for a different reason, by https://gitlab.com/YottaDB/DB/YDB/issues/309 in the upcoming YottaDB release r1.24. We will update the final release note in that link to indicate your symptom too as being fixed. You should be able to build from the latest code and verify your use case works fine. If not, let us know.

@nars1 nars1 closed this as completed Dec 12, 2018
ChristopherEdwards pushed a commit to ChristopherEdwards/YottaDB that referenced this issue Jun 3, 2019
… closed after a TPTIMEOUT error during READ

See https://gitlab.com/YottaDB/DB/YDB/issues/348 for background/details.

The crux of the issue is that a TPTIMEOUT error (which causes "outofband" to be set to "tptimeout")
triggers the same actions that a job interrupt (MUPIP INTRPT) does in case of a SOCKET READ even though
the former does not restart the READ (since it triggers error processing) whereas the latter does
restart the read once it is done with executing $ZINTERRUPT M code.

This seems to be an issue that was missed out in GT.M V6.1-000 as part of GTM-7835 (see below release note).
There were 3 socket modules that could set dsocketptr->mupintr to TRUE (implying a socket action was
interrupted by a MUPIP INTRPT and needs to be restarted later). They were
	1) iosocket_wait.c,
	2) iosocket_connect.c
	3) iosocket_readfl.c

The first 2 of them were fixed to handle restartable issues in V6.1-000 but the last one was not.
Fixing iosocket_readfl.c just like the other two modules (to use OUTOFBAND_RESTARTABLE macro
to check if the "outofband" action is restartable or not and only set mupintr if it is restartable)
automatically fixes YottaDB#348.
ChristopherEdwards pushed a commit to ChristopherEdwards/YottaDB that referenced this issue Jun 3, 2019
…o a regression in a prior YottaDB#348 commit

The YottaDB#348 prior commit had removed a local variable "outofband_terminate" in iosocket_readfl.c and
instead replaced it with the global variable "outofband". But this is incorrect in case the only
string read in this invocation of the function is a delimiter and an outofband event (job interrupt)
simultaneously happens which would cause the delimiter to be ignored when saving the current
state of the read (to handle the job interrupt) resulting in data loss on the READ side of the socket.
Using the "outofband_terminate" local variable guarantees we do the save of the current read state
only if we have not yet seen a terminator and we see an outofband.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants