8:11 a.m.
In exec_input_file():
1375 if (!(pc->flags & SILENT)) {
1376 fprintf(fp, "%s%s", pc->prompt, buf);
This "fp" variable needs to be "stdout".
The prompting and echoing of input commands needs to go there,
not whereever "fp" is currently pointing (crash command output).
$ diff -u *~ cmdline.c
--- cmdline.c~ 2012-02-03 11:22:33.000000000 -0800
+++ cmdline.c 2012-02-15 16:51:07.209524248 -0800
@@ -1372,10 +1372,8 @@
if (!(argcnt = parse_line(pc->command_line, args)))
continue;
- if (!(pc->flags & SILENT)) {
- fprintf(fp, "%s%s", pc->prompt, buf);
- fflush(fp);
- }
+ if (!(pc->flags & SILENT))
+ printf("%s%s", pc->prompt, buf);
exec_command();
}
9:59 a.m.
----- Original Message -----
In exec_input_file():
1375 if (!(pc->flags & SILENT)) {
1376 fprintf(fp, "%s%s", pc->prompt, buf);
This "fp" variable needs to be "stdout".
The prompting and echoing of input commands needs to go there,
not whereever "fp" is currently pointing (crash command output).
I'm not sure I agree...
$ diff -u *~ cmdline.c
--- cmdline.c~ 2012-02-03 11:22:33.000000000 -0800
+++ cmdline.c 2012-02-15 16:51:07.209524248 -0800
@@ -1372,10 +1372,8 @@
if (!(argcnt = parse_line(pc->command_line, args)))
continue;
- if (!(pc->flags & SILENT)) {
- fprintf(fp, "%s%s", pc->prompt, buf);
- fflush(fp);
- }
+ if (!(pc->flags & SILENT))
+ printf("%s%s", pc->prompt, buf);
exec_command();
}
Can you show an example of the problem that you're trying
to handle?
Also, printf() is never used by the crash utility. (well, except
by some dead va_server.c code, some dead remote.c debug code,
and a couple places in s390dbf.c which I don't control...)
Dave
12:08 p.m.
$ cat > test-in <<_EOF_
+ mod | cat > test-out
+ _EOF_
$ crash [....]
crash> < test-in
crash> quit
$ cat test-out
crash> mod | cat > test-out
MODULE NAME SIZE OBJECT FILE
[....]
That first line does not belong in "test-out".
It is very noticeable if "cat" were trying to parse the "mod" output.
WRT printf, you can always add another global: trace_fp
and let that one be the fp for writing trace logs. But it should
always be stdout. (Well, "stderr", actually, but you are already
printing your command traces to stdout.)
On Thu, Feb 16, 2012 at 7:59 AM, Dave Anderson <anderson(a)redhat.com> wrote:
I'm not sure I agree...
> $ diff -u *~ cmdline.c
> --- cmdline.c~ 2012-02-03 11:22:33.000000000 -0800
> +++ cmdline.c 2012-02-15 16:51:07.209524248 -0800
> @@ -1372,10 +1372,8 @@
> if (!(argcnt = parse_line(pc->command_line, args)))
> continue;
>
> - if (!(pc->flags & SILENT)) {
> - fprintf(fp, "%s%s", pc->prompt, buf);
> - fflush(fp);
> - }
> + if (!(pc->flags & SILENT))
> + printf("%s%s", pc->prompt, buf);
>
> exec_command();
> }
Can you show an example of the problem that you're trying
to handle?
Also, printf() is never used by the crash utility. (well, except
by some dead va_server.c code, some dead remote.c debug code,
and a couple places in s390dbf.c which I don't control...)
Dave
12:39 p.m.
----- Original Message -----
$ cat > test-in <<_EOF_
+ mod | cat > test-out
+ _EOF_
$ crash [....]
crash> < test-in
crash> quit
$ cat test-out
crash> mod | cat > test-out
MODULE NAME SIZE OBJECT FILE
[....]
That first line does not belong in "test-out".
It is very noticeable if "cat" were trying to parse the "mod"
output.
WRT printf, you can always add another global: trace_fp
and let that one be the fp for writing trace logs. But it should
always be stdout. (Well, "stderr", actually, but you are already
printing your command traces to stdout.)
What happens when the "silent" environment variable is set "on"?
(i.e., run "crash -s ..." or enter "set silent on" during runtime)
Dave
On Thu, Feb 16, 2012 at 7:59 AM, Dave Anderson
<anderson(a)redhat.com>
wrote:
>
> I'm not sure I agree...
>
>> $ diff -u *~ cmdline.c
>> --- cmdline.c~ 2012-02-03 11:22:33.000000000 -0800
>> +++ cmdline.c 2012-02-15 16:51:07.209524248 -0800
>> @@ -1372,10 +1372,8 @@
>> if (!(argcnt = parse_line(pc->command_line,
>> args)))
>> continue;
>>
>> - if (!(pc->flags & SILENT)) {
>> - fprintf(fp, "%s%s", pc->prompt, buf);
>> - fflush(fp);
>> - }
>> + if (!(pc->flags & SILENT))
>> + printf("%s%s", pc->prompt, buf);
>>
>> exec_command();
>> }
>
> Can you show an example of the problem that you're trying
> to handle?
>
> Also, printf() is never used by the crash utility. (well, except
> by some dead va_server.c code, some dead remote.c debug code,
> and a couple places in s390dbf.c which I don't control...)
>
> Dave
12:57 p.m.
On 02/16/12 10:39, Dave Anderson wrote:
----- Original Message -----
> $ cat> test-in<<_EOF_
> + mod | cat> test-out
> + _EOF_
> $ crash [....]
> crash> < test-in
> crash> quit
> $ cat test-out
> crash> mod | cat> test-out
> MODULE NAME SIZE OBJECT FILE
> [....]
>
> That first line does not belong in "test-out".
> It is very noticeable if "cat" were trying to parse the "mod"
output.
> WRT printf, you can always add another global: trace_fp
> and let that one be the fp for writing trace logs. But it should
> always be stdout. (Well, "stderr", actually, but you are already
> printing your command traces to stdout.)
What happens when the "silent" environment variable is set "on"?
(i.e., run "crash -s ..." or enter "set silent on" during runtime)
Obviously, that would not happen. The issue is that the behavior
is completely unanticipatable. When you type in:
crash> mod | cat > test-out
you get what you expect in "test-out". When you put that into
a sourced file, you get different results. That is wrong, without
regard to any silent settings. The cause is this command trace stuff
that gets inserted into the command output stream. It doesn't belong.
Would you fix it, please? Thank you.
1:06 p.m.
----- Original Message -----
On 02/16/12 10:39, Dave Anderson wrote:
>
>
> ----- Original Message -----
>> $ cat> test-in<<_EOF_
>> + mod | cat> test-out
>> + _EOF_
>> $ crash [....]
>> crash> < test-in
>> crash> quit
>> $ cat test-out
>> crash> mod | cat> test-out
>> MODULE NAME SIZE OBJECT FILE
>> [....]
>>
>> That first line does not belong in "test-out".
>> It is very noticeable if "cat" were trying to parse the
"mod" output.
>> WRT printf, you can always add another global: trace_fp
>> and let that one be the fp for writing trace logs. But it should
>> always be stdout. (Well, "stderr", actually, but you are already
>> printing your command traces to stdout.)
>
> What happens when the "silent" environment variable is set
"on"?
> (i.e., run "crash -s ..." or enter "set silent on" during
runtime)
Obviously, that would not happen. The issue is that the behavior
is completely unanticipatable. When you type in:
crash> mod | cat > test-out
you get what you expect in "test-out". When you put that into
a sourced file, you get different results. That is wrong, without
regard to any silent settings. The cause is this command trace stuff
that gets inserted into the command output stream. It doesn't
belong.
Would you fix it, please? Thank you.
No, I won't. You're welcome.
This discussion came up many years ago. Some people want the command
interspersed and others do not. The "silent" variable was the compromise.
But, that's the beauty of open source -- you can do whatever you'd like
with your copy.
Dave
1:44 p.m.
On 02/16/12 11:06, Dave Anderson wrote:
> Would you fix it, please? Thank you.
No, I won't. You're welcome.
This discussion came up many years ago. Some people want the command
interspersed and others do not. The "silent" variable was the compromise.
Ick. Backup plan: add "<" to the list of commands that get help
and make a note (strongly :) that any command output redirected to
shell commands will get the command prompt and full command line
sent to it as well. It is very unexpected. Perhaps an example
like the one I sent showing the merged text. Advertise the feature
so it won't bite so hard.
Thank you!
$ cat test-in
mod | cat > test-out
$ crash [.....]
crash> < test-in
crash> quit
$ cat test-out
crash> mod | cat > test-out
MODULE NAME SIZE OBJECT FILE
ffffffffa0001200 craytrace 6284 (not loaded) [CONFIG_KALLSYMS]
[...]
1:54 p.m.
----- Original Message -----
On 02/16/12 11:06, Dave Anderson wrote:
>> Would you fix it, please? Thank you.
>
> No, I won't. You're welcome.
>
> This discussion came up many years ago. Some people want the command
> interspersed and others do not. The "silent" variable was the
> compromise.
Ick. Backup plan: add "<" to the list of commands that get help
and make a note (strongly :) that any command output redirected to
shell commands will get the command prompt and full command line
sent to it as well. It is very unexpected. Perhaps an example
like the one I sent showing the merged text. Advertise the feature
so it won't bite so hard.
The usage of "<" is part of the "help input" page. And the
"silent"
variable is described in the "set" help page.
Dave
3:02 a.m.
Hi Dave,
On Thu, 2012-02-16 at 10:59 -0500, Dave Anderson wrote:
Also, printf() is never used by the crash utility. (well, except
by some dead va_server.c code, some dead remote.c debug code,
and a couple places in s390dbf.c which I don't control...)
Probably I should change that in s390dbf.c. Should I always use
fprintf(fp, ...)? Also for error messages?
Michael
7:48 a.m.
----- Original Message -----
Hi Dave,
On Thu, 2012-02-16 at 10:59 -0500, Dave Anderson wrote:
> Also, printf() is never used by the crash utility. (well, except
> by some dead va_server.c code, some dead remote.c debug code,
> and a couple places in s390dbf.c which I don't control...)
Probably I should change that in s390dbf.c. Should I always use
fprintf(fp, ...)? Also for error messages?
Ideally, yes, and error() with the proper type for error messages.
Dave
4806
days inactive
4807
days old
devel@lists.crash-utility.osci.io
9 comments
3 participants
participants (3)
-
Bruce Korb -
Dave Anderson -
Michael Holzheu