On Tue, May 30, 2023 at 10:31 AM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com> wrote:
On 2023/05/28 5:17, Hsin-Yi Wang wrote:
> hi crash-utility community,
>
> When stdin is not a TTY, but all the other flags remain the same,
> prompt ("crash> ") won't be displayed. An example use case is, the
> stdin of crash is replaced by a piped fd connected to another process.
>
> In process_command_line(), it checks if pc->flags does NOT have any of
> the flag: READLINE|SILENT|CMDLINE_IFILE|RCHOME_IFILE|RCLOCAL_IFILE, a
> prompt should be printed.
>
> But in setup_environment(), pc->flags is set to have READLINE flag[2],
> the above check will not be true at all.
>
> Should READLINE be set for all cases in setup_environment()?
> - If true, should the check in process_command_line() look for TTY
> instead of READLINE? Since if pc->flags has TTY, [2] won't be true and
> the prompt will be printed later in TTY's case[3].
> - If false, where should be a proper place and conditions to set READLINE?
>
> Or is the current behavior intended? I may not fully understand the
> design logic. Any explanations are appreciated.
I don't know the full history of crash, but my impression of the flag is
that probably it's an ancient code and almost meaningless now, but the
current behavior is intended.
What you want to do is displaying the prompt and command without a tty?
Interact with crash through another process that piped stdin/stdout
with crash to do additional input/output processing, so the filemode
won't work.
This is also my imagination, but probably they wanted only command
output like this without the prompt and command:
# echo sys | crash -s
KERNEL: /usr/lib/debug/lib/modules/4.18.0-305.el8.x86_64/vmlinux
DUMPFILE: /proc/kcore
CPUS: 16
DATE: Tue May 30 11:15:41 JST 2023
UPTIME: 19 days, 23:23:48
LOAD AVERAGE: 0.18, 0.12, 0.09
TASKS: 555
NODENAME: r110j-1
RELEASE: 4.18.0-305.el8.x86_64
VERSION: #1 SMP Thu Apr 29 08:54:30 EDT 2021
MACHINE: x86_64 (3400 Mhz)
MEMORY: 63.9 GB
#
But I wonder if the current behavior is intended, wouldn't [1] never
be run because of [2]?
[1]
https://github.com/crash-utility/crash/blob/05a3a328fcd8920e49926b6d1c9c8...
[2]
https://github.com/crash-utility/crash/blob/8246dce99dd23457e8c7a3fe9609c...
Another not necessarily related data point is, I compared the gdb tool
and it will also give the prompt if no tty presented.
Because if they wanted the prompt and command, it would be easily done
like this...
--- a/cmdline.c
+++ b/cmdline.c
@@ -139,6 +139,7 @@ process_command_line(void)
} else {
if (fgets(pc->command_line, BUFSIZE-1, stdin) == NULL)
clean_exit(1);
+ fprintf(fp, "%s%s", pc->prompt, pc->command_line);
clean_line(pc->command_line);
strcpy(pc->orig_line, pc->command_line);
}
Yeah, maybe print this before the fgets with fflush()? similar to [1],
or does the following make sense?
diff --git a/cmdline.c b/cmdline.c
index ded6551..181800a 100644
--- a/cmdline.c
+++ b/cmdline.c
@@ -65,7 +65,7 @@ process_command_line(void)
BZERO(pc->command_line, BUFSIZE);
if (!(pc->flags &
- (READLINE|SILENT|CMDLINE_IFILE|RCHOME_IFILE|RCLOCAL_IFILE)))
+ (TTY|SILENT|CMDLINE_IFILE|RCHOME_IFILE|RCLOCAL_IFILE)))
fprintf(fp, "%s", pc->prompt);
fflush(fp);
If you want the prompt and command with pre-generated crash commands,
you can use "crash -i" option. How about this?
Filemode is not ideal if we want to pipe crash with another process
that users interact with, since we will have to load vmlinux and
dumpfile every time.
But if this still looks like working as intended, I will close this issue.
Thanks for your reply.