RFA: >, >>, and "tee" operators

RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

Here we go.  They only work quite right for the CLI; they sort-of work for
other front-ends, and print a warning to that effect.  Documentation
included.  These are pretty much how Tom originally did them:

> file
>> file

and my additions:
tee file
tee -a file

Any of the commands without a filename will end redirection.

Comments?  OK to apply?  Design too ugly?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-07-23  Tom Tromey  <tromey@redhat.com>
            Daniel Jacobowitz  <drow@mvista.com>

	* cli-out.c (struct ui_out_data): Add original_stream.
	(cli_redirect): New function.
	(cli_ui_out_impl): Add cli_redirect.
	(cli_out_new): Initialize original_stream.
	* ui-file.c (struct tee_file, tee_file_new, tee_file_delete)
	(tee_file_flush, tee_file_write, tee_file_fputs)
	(tee_file_isatty): New.
	* ui-file.h (tee_file_new): Add prototype.
	* ui-out.c (default_ui_out_impl): Add NULL for redirect member.
	(uo_redirect, ui_out_redirect): New.
	* ui-out.h (struct ui_out_impl): Add redirect member.
	(redirect_ftype): New.
        * cli/cli-decode.c (lookup_cmd): Allow `>' in command name.
        (lookup_cmd_1): Likewise.
        * top.c (redirect_output): New function.
        (append_output): Likewise.
        (handle_redirections): Likewise.
        (pop_output_files): Likewise.
        (init_main): Create ">", ">>", and "tee" commands.

2002-07-23  Daniel Jacobowitz  <drow@mvista.com>

	* mi-out.c (mi_ui_out_impl): Add NULL for redirect member.

2002-07-23  Daniel Jacobowitz  <drow@mvista.com>

	* tui-out.c (tui_ui_out_impl): Add NULL for redirect member.

2002-07-23  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.texinfo (Redirecting output): New chapter.

Index: cli-out.c
===================================================================
RCS file: /cvs/src/src/gdb/cli-out.c,v
retrieving revision 1.14
diff -u -p -r1.14 cli-out.c
--- cli-out.c	19 Mar 2002 02:51:04 -0000	1.14
+++ cli-out.c	23 Jul 2002 18:26:19 -0000
@@ -31,6 +31,7 @@
 struct ui_out_data
   {
     struct ui_file *stream;
+    struct ui_file *original_stream;
     int suppress_output;
   };
 
@@ -63,6 +64,7 @@ static void cli_message (struct ui_out *
 			 const char *format, va_list args);
 static void cli_wrap_hint (struct ui_out *uiout, char *identstring);
 static void cli_flush (struct ui_out *uiout);
+static int cli_redirect (struct ui_out *uiout, struct ui_file *outstream);
 
 /* This is the CLI ui-out implementation functions vector */
 
@@ -86,6 +88,7 @@ static struct ui_out_impl cli_ui_out_imp
   cli_message,
   cli_wrap_hint,
   cli_flush,
+  cli_redirect,
   0, /* Does not need MI hacks (i.e. needs CLI hacks).  */
 };
 
@@ -323,6 +326,24 @@ cli_flush (struct ui_out *uiout)
   gdb_flush (data->stream);
 }
 
+int
+cli_redirect (struct ui_out *uiout, struct ui_file *outstream)
+{
+  struct ui_out_data *data = ui_out_data (uiout);
+  if (outstream != NULL)
+    {
+      data->original_stream = data->stream;
+      data->stream = outstream;
+    }
+  else if (data->original_stream != NULL)
+    {
+      data->stream = data->original_stream;
+      data->original_stream = NULL;
+    }
+
+  return 0;
+}
+
 /* local functions */
 
 /* Like cli_field_fmt, but takes a variable number of args
@@ -361,6 +382,7 @@ cli_out_new (struct ui_file *stream)
 
   struct ui_out_data *data = XMALLOC (struct ui_out_data);
   data->stream = stream;
+  data->original_stream = NULL;
   data->suppress_output = 0;
   return ui_out_new (&cli_ui_out_impl, data, flags);
 }
Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.64
diff -u -p -r1.64 top.c
--- top.c	11 Jul 2002 13:50:49 -0000	1.64
+++ top.c	23 Jul 2002 18:26:19 -0000
@@ -1707,6 +1707,133 @@ dont_repeat_command (char *ignored, int 
 				   necessarily reading from stdin.  */
 }
 \f
+/* Functions and variables for gdb output redirection.  */
+
+/* These hold the pushed copies of the gdb output files.
+   If NULL then nothing has yet been pushed.  */
+static struct ui_file *saved_stdout;
+static struct ui_file *saved_stderr;
+static struct ui_file *saved_stdlog;
+static struct ui_file *saved_stdtarg;
+static char *saved_filename;
+
+/* If we've pushed output files, close them and pop them.  */
+static void
+pop_output_files ()
+{
+  if (saved_stdout != NULL)
+    {
+      xfree (saved_filename);
+      saved_filename = NULL;
+
+      /* Only delete one of the files -- they are all set to the same
+	 value.  */
+      ui_file_delete (gdb_stdout);
+      gdb_stdout = saved_stdout;
+      gdb_stderr = saved_stderr;
+      gdb_stdlog = saved_stdlog;
+      gdb_stdtarg = saved_stdtarg;
+      saved_stdout = NULL;
+      saved_stderr = NULL;
+      saved_stdlog = NULL;
+      saved_stdtarg = NULL;
+
+      ui_out_redirect (uiout, NULL);
+    }
+}
+
+/* This is a helper for the `>', `>>', and `tee' redirection commands.  */
+static void
+handle_redirections (char *command, char *filename, char *mode, int tee)
+{
+  struct ui_file *output;
+
+  if (saved_filename != NULL)
+    fprintf_unfiltered (saved_stdout, "Done redirecting to %s.\n", saved_filename);
+
+  pop_output_files ();
+
+  /* Skip whitespace.  */
+  if (filename == NULL)
+    return;
+
+  while (*filename && isspace (*filename))
+    ++filename;
+  
+  if (*filename == 0)
+    return;
+
+  /* It would be nice if the syntax was:
+     > FILE [COMMAND]
+     .. if COMMAND is specified then it (and only it) is run with
+     redirections.  This means inventing a quoting syntax for the file
+     name though.  */
+  output = gdb_fopen (filename, mode);
+  if (output == NULL)
+    perror_with_name (command);
+
+  /* Redirects everything to gdb_stdout while this is running.  */
+  if (tee)
+    {
+      output = tee_file_new (gdb_stdout, 0, output, 1);
+      if (output == NULL)
+	perror_with_name (command);
+      fprintf_unfiltered (gdb_stdout, "Copying output to %s.\n", filename);
+    }
+  else
+    fprintf_unfiltered (gdb_stdout, "Redirecting output to %s.\n", filename);
+
+  saved_filename = xstrdup (filename);
+  saved_stdout = gdb_stdout;
+  saved_stderr = gdb_stderr;
+  saved_stdlog = gdb_stdlog;
+  saved_stdtarg = gdb_stdtarg;
+  gdb_stdout = output;
+  gdb_stderr = output;
+  gdb_stdlog = output;
+  gdb_stdtarg = output;
+  if (ui_out_redirect (uiout, gdb_stdout) < 0)
+    warning ("Current output protocol does not support redirection");
+}
+
+/* Redirect output by overwriting a file.  */
+/* ARGSUSED */
+static void
+redirect_output (char *args, int from_tty)
+{
+  handle_redirections (">", args, "w", 0);
+}
+
+/* Redirect output by appending to a file.  */
+/* ARGSUSED */
+static void
+append_output (char *args, int from_tty)
+{
+  handle_redirections (">>", args, "a", 0);
+}
+
+/* Redirect output by writing to a file and writing to the screen.  */
+/* ARGSUSED */
+static void
+tee_output (char *args, int from_tty)
+{
+  if (args)
+    {
+      /* Check for "-a".  */
+      while (*args && isspace (*args))
+	++args;
+
+      if (args[0] == '-' && args[1] == 'a' && isspace (args[2]))
+	{
+	  handle_redirections ("tee", args + 3, "a", 1);
+	  return;
+	}
+    }
+
+  handle_redirections ("tee", args, "w", 1);
+}
+
+\f
 /* Functions to manipulate command line editing control variables.  */
 
 /* Number of commands to print in each call to show_commands.  */
@@ -2040,6 +2167,17 @@ ie. the number of previous commands to k
 Use \"on\" to enable the notification, and \"off\" to disable it.", &setlist),
 	 &showlist);
     }
+
+  add_com (">", no_class, redirect_output,
+	   "Redirect further gdb output to a file.\n\
+If no filename is given, any previous redirection is stopped.");
+  add_com (">>", no_class, append_output,
+	   "Append further gdb output to a file.\n\
+If no filename is given, any previous redirection is stopped.");
+  add_com ("tee", no_class, tee_output,
+	   "Send further gdb output to both the terminal and a file.\n\
+If \"-a\" is specified append to the file; otherwise overwrite it.\n\
+If no filename is given, any previous redirection is stopped.");
 }
 
 void
Index: ui-file.c
===================================================================
RCS file: /cvs/src/src/gdb/ui-file.c,v
retrieving revision 1.8
diff -u -p -r1.8 ui-file.c
--- ui-file.c	19 Mar 2002 02:51:07 -0000	1.8
+++ ui-file.c	23 Jul 2002 18:26:19 -0000
@@ -483,3 +483,97 @@ gdb_fopen (char *name, char *mode)
     return NULL;
   return stdio_file_new (f, 1);
 }
+
+/* ``struct ui_file'' implementation that maps onto two ui-file objects.  */
+
+static ui_file_write_ftype tee_file_write;
+static ui_file_fputs_ftype tee_file_fputs;
+static ui_file_isatty_ftype tee_file_isatty;
+static ui_file_delete_ftype tee_file_delete;
+static ui_file_flush_ftype tee_file_flush;
+
+static int tee_file_magic;
+
+struct tee_file
+  {
+    int *magic;
+    struct ui_file *one, *two;
+    int close_one, close_two;
+  };
+
+struct ui_file *
+tee_file_new (struct ui_file *one, int close_one,
+	      struct ui_file *two, int close_two)
+{
+  struct ui_file *ui_file = ui_file_new ();
+  struct tee_file *tee = xmalloc (sizeof (struct tee_file));
+  tee->magic = &tee_file_magic;
+  tee->one = one;
+  tee->two = two;
+  tee->close_one = close_one;
+  tee->close_two = close_two;
+  set_ui_file_data (ui_file, tee, tee_file_delete);
+  set_ui_file_flush (ui_file, tee_file_flush);
+  set_ui_file_write (ui_file, tee_file_write);
+  set_ui_file_fputs (ui_file, tee_file_fputs);
+  set_ui_file_isatty (ui_file, tee_file_isatty);
+  return ui_file;
+}
+
+static void
+tee_file_delete (struct ui_file *file)
+{
+  struct tee_file *tee = ui_file_data (file);
+  if (tee->magic != &tee_file_magic)
+    internal_error (__FILE__, __LINE__,
+		    "tee_file_delete: bad magic number");
+  if (tee->close_one)
+    ui_file_delete (tee->one);
+  if (tee->close_two)
+    ui_file_delete (tee->two);
+
+  xfree (tee);
+}
+
+static void
+tee_file_flush (struct ui_file *file)
+{
+  struct tee_file *tee = ui_file_data (file);
+  if (tee->magic != &tee_file_magic)
+    internal_error (__FILE__, __LINE__,
+		    "tee_file_flush: bad magic number");
+  tee->one->to_flush (tee->one);
+  tee->two->to_flush (tee->two);
+}
+
+static void
+tee_file_write (struct ui_file *file, const char *buf, long length_buf)
+{
+  struct tee_file *tee = ui_file_data (file);
+  if (tee->magic != &tee_file_magic)
+    internal_error (__FILE__, __LINE__,
+		    "tee_file_write: bad magic number");
+  ui_file_write (tee->one, buf, length_buf);
+  ui_file_write (tee->two, buf, length_buf);
+}
+
+static void
+tee_file_fputs (const char *linebuffer, struct ui_file *file)
+{
+  struct tee_file *tee = ui_file_data (file);
+  if (tee->magic != &tee_file_magic)
+    internal_error (__FILE__, __LINE__,
+		    "tee_file_fputs: bad magic number");
+  tee->one->to_fputs (linebuffer, tee->one);
+  tee->two->to_fputs (linebuffer, tee->two);
+}
+
+static int
+tee_file_isatty (struct ui_file *file)
+{
+  struct tee_file *tee = ui_file_data (file);
+  if (tee->magic != &tee_file_magic)
+    internal_error (__FILE__, __LINE__,
+		    "tee_file_isatty: bad magic number");
+  return (0);
+}
Index: ui-file.h
===================================================================
RCS file: /cvs/src/src/gdb/ui-file.h,v
retrieving revision 1.2
diff -u -p -r1.2 ui-file.h
--- ui-file.h	6 Mar 2001 08:21:17 -0000	1.2
+++ ui-file.h	23 Jul 2002 18:26:19 -0000
@@ -90,4 +90,11 @@ extern struct ui_file *stdio_fileopen (F
 /* Open NAME returning an STDIO based UI_FILE. */
 extern struct ui_file *gdb_fopen (char *name, char *mode);
 
+/* Create a file which writes to both ONE and TWO.  CLOSE_ONE
+   and CLOSE_TWO indicate whether the original files should be
+   closed when the new file is closed.  */
+struct ui_file *tee_file_new (struct ui_file *one,
+			      int close_one,
+			      struct ui_file *two,
+			      int close_two);
 #endif
Index: ui-out.c
===================================================================
RCS file: /cvs/src/src/gdb/ui-out.c,v
retrieving revision 1.22
diff -u -p -r1.22 ui-out.c
--- ui-out.c	5 May 2002 03:17:21 -0000	1.22
+++ ui-out.c	23 Jul 2002 18:26:20 -0000
@@ -206,6 +206,7 @@ struct ui_out_impl default_ui_out_impl =
   default_message,
   default_wrap_hint,
   default_flush,
+  NULL,
   0, /* Does not need MI hacks.  */
 };
 
@@ -254,6 +255,7 @@ static void uo_message (struct ui_out *u
 			const char *format, va_list args);
 static void uo_wrap_hint (struct ui_out *uiout, char *identstring);
 static void uo_flush (struct ui_out *uiout);
+static int uo_redirect (struct ui_out *uiout, struct ui_file *outstream);
 
 /* Prototypes for local functions */
 
@@ -639,6 +641,12 @@ ui_out_flush (struct ui_out *uiout)
   uo_flush (uiout);
 }
 
+int
+ui_out_redirect (struct ui_out *uiout, struct ui_out *outstream)
+{
+  uo_redirect (uiout, outstream);
+}
+
 /* set the flags specified by the mask given */
 int
 ui_out_set_flags (struct ui_out *uiout, int mask)
@@ -980,6 +988,14 @@ uo_flush (struct ui_out *uiout)
   if (!uiout->impl->flush)
     return;
   uiout->impl->flush (uiout);
+}
+
+int
+uo_redirect (struct ui_out *uiout, struct ui_file *outstream)
+{
+  if (!uiout->impl->redirect)
+    return -1;
+  uiout->impl->redirect (uiout, outstream);
 }
 
 /* local functions */
Index: ui-out.h
===================================================================
RCS file: /cvs/src/src/gdb/ui-out.h,v
retrieving revision 1.15
diff -u -p -r1.15 ui-out.h
--- ui-out.h	6 Jul 2001 03:53:11 -0000	1.15
+++ ui-out.h	23 Jul 2002 18:26:20 -0000
@@ -237,6 +237,8 @@ typedef void (message_ftype) (struct ui_
 			      const char *format, va_list args);
 typedef void (wrap_hint_ftype) (struct ui_out * uiout, char *identstring);
 typedef void (flush_ftype) (struct ui_out * uiout);
+typedef int (redirect_ftype) (struct ui_out * uiout,
+			      struct ui_file * outstream);
 
 /* ui-out-impl */
 
@@ -260,6 +262,7 @@ struct ui_out_impl
     message_ftype *message;
     wrap_hint_ftype *wrap_hint;
     flush_ftype *flush;
+    redirect_ftype *redirect;
     int is_mi_like_p;
   };
 
Index: cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.27
diff -u -p -r1.27 cli-decode.c
--- cli/cli-decode.c	3 Jul 2002 17:35:21 -0000	1.27
+++ cli/cli-decode.c	23 Jul 2002 18:26:20 -0000
@@ -923,7 +923,7 @@ lookup_cmd_1 (char **text, struct cmd_li
      so that "set args_foo()" doesn't get interpreted as
      "set args _foo()".  */
   for (p = *text;
-       *p && (isalnum (*p) || *p == '-' || *p == '_' ||
+       *p && (isalnum (*p) || *p == '-' || *p == '_' || *p == '>' || 
 	      (tui_version &&
 	       (*p == '+' || *p == '<' || *p == '>' || *p == '$')) ||
 	      (xdb_commands && (*p == '!' || *p == '/' || *p == '?')));
@@ -1086,7 +1086,7 @@ lookup_cmd (char **line, struct cmd_list
 	    {
 	      char *p = *line, *q;
 
-	      while (isalnum (*p) || *p == '-')
+	      while (isalnum (*p) || *p == '-' || *p == '>')
 		p++;
 
 	      q = (char *) alloca (p - *line + 1);
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.104
diff -u -p -r1.104 gdb.texinfo
--- doc/gdb.texinfo	9 Jul 2002 15:59:18 -0000	1.104
+++ doc/gdb.texinfo	23 Jul 2002 18:26:24 -0000
@@ -752,6 +752,7 @@ type @kbd{quit} or @kbd{C-d} to exit.
 * Invoking GDB::                How to start @value{GDBN}
 * Quitting GDB::                How to quit @value{GDBN}
 * Shell Commands::              How to use shell commands inside @value{GDBN}
+* Redirecting output::          How to redirect @value{GDBN}'s output to files
 @end menu
 
 @node Invoking GDB
@@ -1201,6 +1202,31 @@ You do not have to use the @code{shell} 
 Execute the @code{make} program with the specified
 arguments.  This is equivalent to @samp{shell make @var{make-args}}.
 @end table
+
+@node Redirecting output
+@section Redirecting output
+
+You may want to save the output of @value{GDBN} commands to a file.
+There are three commands to control @value{GDBN}'s logging.
+
+@table @code
+@kindex >
+@cindex redirect
+@item > @var{file}
+Redirect all output to @var{file}, overwriting it.
+@kindex >>
+@cindex append
+@item >> @var{file}
+Redirect all output to @var{file}, appending to it.
+@kindex tee
+@cindex tee
+@item tee [-a] @var{file}
+Copy output to both the screen and @var{file}, overwriting it unless -a
+(append) is specified.
+@end table
+
+To end the redirection and return to normal output, just use any of the
+redirection commands without specifying a filename.
 
 @node Commands
 @chapter @value{GDBN} Commands
Index: mi/mi-out.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-out.c,v
retrieving revision 1.23
diff -u -p -r1.23 mi-out.c
--- mi/mi-out.c	19 Mar 2002 02:51:08 -0000	1.23
+++ mi/mi-out.c	23 Jul 2002 18:26:25 -0000
@@ -85,6 +85,7 @@ struct ui_out_impl mi_ui_out_impl =
   mi_message,
   mi_wrap_hint,
   mi_flush,
+  NULL,
   1, /* Needs MI hacks.  */
 };
 
Index: tui/tui-out.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui-out.c,v
retrieving revision 1.2
diff -u -p -r1.2 tui-out.c
--- tui/tui-out.c	19 Mar 2002 02:51:09 -0000	1.2
+++ tui/tui-out.c	23 Jul 2002 18:26:25 -0000
@@ -88,6 +88,7 @@ static struct ui_out_impl tui_ui_out_imp
   tui_message,
   tui_wrap_hint,
   tui_flush,
+  NULL,
   0, /* Does not need MI hacks (i.e. needs CLI hacks).  */
 };
 

Re: RFA: >, >>, and "tee" operators

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

Daniel> Here we go.  They only work quite right for the CLI; they
Daniel> sort-of work for other front-ends, and print a warning to that
Daniel> effect.  Documentation included.  These are pretty much how
Daniel> Tom originally did them:

You'll hate to hear this, but I ended up rewriting the patch to be a
`transcript' command.  The follow-on discussion to my original patch
convinced me that the names ">" and ">>" weren't that great.  Also,
going this route let me remove some of the hacks in cli/.

The new usage I implemented is:

    transcript > FILE
    transcript >> FILE
    transcript | COMMAND

I never submitted my rewrite since I hadn't addressed the one
remaining problem, namely teeing.  I can send it if you want it.

Daniel> tee file
Daniel> tee -a file

Maybe tee should be the default?  My experiments using the transcript
code indicated to me that it is hard to use gdb when you don't see the
output...

Tom

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Tue, Jul 23, 2002 at 01:17:04PM -0600, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> Daniel> Here we go.  They only work quite right for the CLI; they
> Daniel> sort-of work for other front-ends, and print a warning to that
> Daniel> effect.  Documentation included.  These are pretty much how
> Daniel> Tom originally did them:
> 
> You'll hate to hear this, but I ended up rewriting the patch to be a
> `transcript' command.  The follow-on discussion to my original patch
> convinced me that the names ">" and ">>" weren't that great.  Also,
> going this route let me remove some of the hacks in cli/.
> 
> The new usage I implemented is:
> 
>     transcript > FILE
>     transcript >> FILE
>     transcript | COMMAND

I don't like this syntax very much.  It looks too much like dumping the
output of a command ("transcript") to the file, not like a redirection
for the future output.  If I were in hard-core shell mode this week I'd
suggest "exec > FILE" but I don't really like that one much either...

Also - is piping to a command actually useful?

> I never submitted my rewrite since I hadn't addressed the one
> remaining problem, namely teeing.  I can send it if you want it.
> 
> Daniel> tee file
> Daniel> tee -a file
> 
> Maybe tee should be the default?  My experiments using the transcript
> code indicated to me that it is hard to use gdb when you don't see the
> output...

Hmm...  How do you feel about:

	transcript [-append] FILE
	tee [-append] FILE

Where transcript replaces ">" and ">>"?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

>> transcript > FILE
>> transcript >> FILE
>> transcript | COMMAND

Daniel> I don't like this syntax very much.  It looks too much like
Daniel> dumping the output of a command ("transcript") to the file,
Daniel> not like a redirection for the future output.

Good point.

Daniel> Also - is piping to a command actually useful?

I don't know.  I haven't even been running with this patch in place,
since the feature in general is only occasionally useful to me.  I
thought I saw a request for this (piping to a command)?

Daniel> Hmm...  How do you feel about:
Daniel> 	transcript [-append] FILE
Daniel> 	tee [-append] FILE
Daniel> Where transcript replaces ">" and ">>"?

That looks good to me.  Or even `transcript [-tee] [-append] FILE'.
Or maybe `[-notee]', with tee as the default.

Tom

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Tue, Jul 23, 2002 at 02:24:15PM -0600, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> >> transcript > FILE
> >> transcript >> FILE
> >> transcript | COMMAND
> 
> Daniel> I don't like this syntax very much.  It looks too much like
> Daniel> dumping the output of a command ("transcript") to the file,
> Daniel> not like a redirection for the future output.
> 
> Good point.
> 
> Daniel> Also - is piping to a command actually useful?
> 
> I don't know.  I haven't even been running with this patch in place,
> since the feature in general is only occasionally useful to me.  I
> thought I saw a request for this (piping to a command)?
> 
> Daniel> Hmm...  How do you feel about:
> Daniel> 	transcript [-append] FILE
> Daniel> 	tee [-append] FILE
> Daniel> Where transcript replaces ">" and ">>"?
> 
> That looks good to me.  Or even `transcript [-tee] [-append] FILE'.
> Or maybe `[-notee]', with tee as the default.

I'd rather have tee as the default, also.  But -notee doesn't look
right, so I left it as two commands.  Anyone else out on the list have
a suggestion?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Grant Edwards]

On Tue, Jul 23, 2002 at 02:24:15PM -0600, Tom Tromey wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> >> transcript > FILE
> >> transcript >> FILE
> >> transcript | COMMAND
> 
> Daniel> I don't like this syntax very much.  It looks too much like
> Daniel> dumping the output of a command ("transcript") to the file,
> Daniel> not like a redirection for the future output.
> 
> Good point.
> 
> Daniel> Also - is piping to a command actually useful?

It would be to me occasionally, though output to a file is 95%
as good.  The one thing I usually need to be able to do is to
put the output of a single command (typically "print") into a
file.

-- 
Grant Edwards
grante@visi.com

Re: RFA: >, >>, and "tee" operators

[Eli Zaretskii]

On Tue, 23 Jul 2002, Daniel Jacobowitz wrote:

> Comments?

Thanks.  The doco changes are approved, with these minor comments:

> +@node Redirecting output
> +@section Redirecting output

Please add here a "@cindex output redirection".

> +@kindex >
> +@cindex redirect
> +@item > @var{file}
> +Redirect all output to @var{file}, overwriting it.
> +@kindex >>
> +@cindex append

The two @cindex entries above should probably be changed in minor ways.  
I would either say "@cindex redirect command" and "@cindex append 
command", or "@cindex rfedirect output to a file" and "@cindex append 
output to a file".

> +@kindex tee
> +@cindex tee

Why is @cindex needed here?  We do have a @kindex with the same text 
already.

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

The changes to ui-file.h and ui-file.c are approved.  That at least 
reduces the patch a bit :-/

I'm pretty sure the tee mechanism will trip up when combined with the 
page mechanism.  That, however, I think is a very separate problem --- 
the page / <more> mechanism needs a major overhaul.

Andrew

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

> On Tue, Jul 23, 2002 at 02:24:15PM -0600, Tom Tromey wrote:
> 
>> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>> 
> 
>> >> transcript > FILE
>> >> transcript >> FILE
>> >> transcript | COMMAND
> 
>> 
>> Daniel> I don't like this syntax very much.  It looks too much like
>> Daniel> dumping the output of a command ("transcript") to the file,
>> Daniel> not like a redirection for the future output.
>> 
>> Good point.
>> 
>> Daniel> Also - is piping to a command actually useful?
>> 
>> I don't know.  I haven't even been running with this patch in place,
>> since the feature in general is only occasionally useful to me.  I
>> thought I saw a request for this (piping to a command)?
>> 
>> Daniel> Hmm...  How do you feel about:
>> Daniel> 	transcript [-append] FILE
>> Daniel> 	tee [-append] FILE
>> Daniel> Where transcript replaces ">" and ">>"?
>> 
>> That looks good to me.  Or even `transcript [-tee] [-append] FILE'.
>> Or maybe `[-notee]', with tee as the default.
> 
> 
> I'd rather have tee as the default, also.  But -notee doesn't look
> right, so I left it as two commands.  Anyone else out on the list have
> a suggestion?

Does the `transcript FILE' command send both the user input (prompts?) 
and output to the file (output also to the console)?  Like unix script?

I guess the corresponding ``tee FILE'' command just writes output?

I think there is also a need for a tempoary redirection.  So I guess 
either the obscure:
	>FILE <command> ...
maybe?
	log FILE <command> .....

GDB's option identifier is ``/'' and not ``-''.  See the print/<FMT> 
commands.  ``-'' has the problem of being a valid expression operator.
I should note that the current parser is pretty broken.  It can't 
differentiate between:
	transcript/f
	transcript /f
(sigh) but that is a fixable problem.

Andrew

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Wed, Jul 24, 2002 at 10:01:03PM -0400, Andrew Cagney wrote:
> >On Tue, Jul 23, 2002 at 02:24:15PM -0600, Tom Tromey wrote:
> >
> >>>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >
> >>
> >
> >>>> transcript > FILE
> >>>> transcript >> FILE
> >>>> transcript | COMMAND
> >
> >>
> >>Daniel> I don't like this syntax very much.  It looks too much like
> >>Daniel> dumping the output of a command ("transcript") to the file,
> >>Daniel> not like a redirection for the future output.
> >>
> >>Good point.
> >>
> >>Daniel> Also - is piping to a command actually useful?
> >>
> >>I don't know.  I haven't even been running with this patch in place,
> >>since the feature in general is only occasionally useful to me.  I
> >>thought I saw a request for this (piping to a command)?
> >>
> >>Daniel> Hmm...  How do you feel about:
> >>Daniel> 	transcript [-append] FILE
> >>Daniel> 	tee [-append] FILE
> >>Daniel> Where transcript replaces ">" and ">>"?
> >>
> >>That looks good to me.  Or even `transcript [-tee] [-append] FILE'.
> >>Or maybe `[-notee]', with tee as the default.
> >
> >
> >I'd rather have tee as the default, also.  But -notee doesn't look
> >right, so I left it as two commands.  Anyone else out on the list have
> >a suggestion?
> 
> Does the `transcript FILE' command send both the user input (prompts?) 
> and output to the file (output also to the console)?  Like unix script?

[Speaking for my patch]

Nope.  Prompts and user input are not logged.  Output goes only to a
file.  Something like `script' might be useful but that's a patch for
another day.

> I guess the corresponding ``tee FILE'' command just writes output?

Output goes to the file and to the normal output channel.  Still no
prompts or input.

> I think there is also a need for a tempoary redirection.  So I guess 
> either the obscure:
> 	>FILE <command> ...
> maybe?
> 	log FILE <command> .....

How about "transcript FILE <command>"?  There's some quoting badness but
for the moment I'm willing to just disallow spaces in the filename. 
Much more straightforward that way.

That doesn't allow for:
  transcript | command args <gdbcommand>
but that's also an OK restriction, I think...

> GDB's option identifier is ``/'' and not ``-''.  See the print/<FMT> 
> commands.  ``-'' has the problem of being a valid expression operator.
> I should note that the current parser is pretty broken.  It can't 
> differentiate between:
> 	transcript/f
> 	transcript /f
> (sigh) but that is a fixable problem.

GDB's option identifier varies, actually; symbol-file -readnow,
add-symbol-file -s <section> <address> are the only two I see offhand. 
We only use / for print format characters.  Mostly we just drop them
all on one line.

I'd rather stick with '-' as it's more familiar to most of our
audience, particularly with 'tee -a'.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Wed, Jul 24, 2002 at 09:49:41PM -0400, Andrew Cagney wrote:
> The changes to ui-file.h and ui-file.c are approved.  That at least 
> reduces the patch a bit :-/
> 
> I'm pretty sure the tee mechanism will trip up when combined with the 
> page mechanism.  That, however, I think is a very separate problem --- 
> the page / <more> mechanism needs a major overhaul.

Thanks, I've committed this:
2002-07-24  Daniel Jacobowitz  <drow@mvista.com>

        * ui-file.c (struct tee_file, tee_file_new, tee_file_delete)
        (tee_file_flush, tee_file_write, tee_file_fputs)
        (tee_file_isatty): New.
        * ui-file.h (tee_file_new): Add prototype.

I'll repost the rest after we decide on what the commands should be
called, and I touch up the documentation.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

> Does the `transcript FILE' command send both the user input (prompts?) 
>> and output to the file (output also to the console)?  Like unix script?
> 
> 
> [Speaking for my patch]
> 
> Nope.  Prompts and user input are not logged.  Output goes only to a
> file.  Something like `script' might be useful but that's a patch for
> another day.

My understanding of a transcript is that it records all details of the 
exchange - both input and output.  Unless the command is recording the 
input, I don't think it should be called ``transcript''.

The name ``transcript'' came about (I think) from an earlier discussion 
where a command to record both input and output was proposed.  See:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=114
for its bug report.

> > I guess the corresponding ``tee FILE'' command just writes output?
> 
> 
> Output goes to the file and to the normal output channel.  Still no
> prompts or input.

Ok.

> I think there is also a need for a tempoary redirection.  So I guess 
>> either the obscure:
>> 	>FILE <command> ...
>> maybe?
>> 	log FILE <command> .....
> 
> 
> How about "transcript FILE <command>"?  There's some quoting badness but
> for the moment I'm willing to just disallow spaces in the filename. 
> Much more straightforward that way.

(See above for problem I see with the name ``transcript''.)

For whitespace in filenames, see:
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=535
So yes, you get to use strchr (' ') .... :-(

> GDB's option identifier is ``/'' and not ``-''.  See the print/<FMT> 
>> commands.  ``-'' has the problem of being a valid expression operator.
>> I should note that the current parser is pretty broken.  It can't 
>> differentiate between:
>> 	transcript/f
>> 	transcript /f
>> (sigh) but that is a fixable problem.
> 
> 
> GDB's option identifier varies, actually; symbol-file -readnow,
> add-symbol-file -s <section> <address> are the only two I see offhand. 
> We only use / for print format characters.  Mostly we just drop them
> all on one line.
> 
> I'd rather stick with '-' as it's more familiar to most of our
> audience, particularly with 'tee -a'.

I think this was raised before (fernando and I discussed it somewhere on 
gdb@).  GDB is used on systems that are not even UNIX like (namely 
DJGPP), trying to tie the syntax to UNIX is such a good idea.  GDB needs 
a syntax spec, the current piece meal aproach is regrettable :-(

If the command was called ``log'' rather than ``tee'' then I don't think 
we would have problems with ``log -a''.  (I'm not saying that log is the 
right name mind.)

enjoy,
Andrew

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Thu, Jul 25, 2002 at 11:46:24AM -0400, Andrew Cagney wrote:
> >Does the `transcript FILE' command send both the user input (prompts?) 
> >>and output to the file (output also to the console)?  Like unix script?
> >
> >
> >[Speaking for my patch]
> >
> >Nope.  Prompts and user input are not logged.  Output goes only to a
> >file.  Something like `script' might be useful but that's a patch for
> >another day.
> 
> My understanding of a transcript is that it records all details of the 
> exchange - both input and output.  Unless the command is recording the 
> input, I don't think it should be called ``transcript''.
> 
> The name ``transcript'' came about (I think) from an earlier discussion 
> where a command to record both input and output was proposed.  See:
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=114
> for its bug report.

OK.  Let's hold the name 'transcript' in reserve for something that can
log both.

> >> I guess the corresponding ``tee FILE'' command just writes output?
> >
> >
> >Output goes to the file and to the normal output channel.  Still no
> >prompts or input.
> 
> Ok.
> 
> >I think there is also a need for a tempoary redirection.  So I guess 
> >>either the obscure:
> >>	>FILE <command> ...
> >>maybe?
> >>	log FILE <command> .....
> >
> >
> >How about "transcript FILE <command>"?  There's some quoting badness but
> >for the moment I'm willing to just disallow spaces in the filename. 
> >Much more straightforward that way.
> 
> (See above for problem I see with the name ``transcript''.)
> 
> For whitespace in filenames, see:
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=535
> So yes, you get to use strchr (' ') .... :-(
> 
> >GDB's option identifier is ``/'' and not ``-''.  See the print/<FMT> 
> >>commands.  ``-'' has the problem of being a valid expression operator.
> >>I should note that the current parser is pretty broken.  It can't 
> >>differentiate between:
> >>	transcript/f
> >>	transcript /f
> >>(sigh) but that is a fixable problem.
> >
> >
> >GDB's option identifier varies, actually; symbol-file -readnow,
> >add-symbol-file -s <section> <address> are the only two I see offhand. 
> >We only use / for print format characters.  Mostly we just drop them
> >all on one line.
> >
> >I'd rather stick with '-' as it's more familiar to most of our
> >audience, particularly with 'tee -a'.
> 
> I think this was raised before (fernando and I discussed it somewhere on 
> gdb@).  GDB is used on systems that are not even UNIX like (namely 
> DJGPP), trying to tie the syntax to UNIX is such a good idea.  GDB needs 
> a syntax spec, the current piece meal aproach is regrettable :-(
> 
> If the command was called ``log'' rather than ``tee'' then I don't think 
> we would have problems with ``log -a''.  (I'm not saying that log is the 
> right name mind.)

Well, I find the DOS-ish '/' separator much nastier than '-' options. 
A question of personal taste.  ``log'' unfortunately is more like
``tee'' than it is like redirection; how about a simple ``redirect''
command?

  redirect [-a[ppend]] FILE [COMMAND]
  log [-a[ppend]] FILE [COMMAND]

I like the sound of those two.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

> I think this was raised before (fernando and I discussed it somewhere on 
>> gdb@).  GDB is used on systems that are not even UNIX like (namely 
>> DJGPP), trying to tie the syntax to UNIX is such a good idea.  GDB needs 
>> a syntax spec, the current piece meal aproach is regrettable :-(
>> 
>> If the command was called ``log'' rather than ``tee'' then I don't think 
>> we would have problems with ``log -a''.  (I'm not saying that log is the 
>> right name mind.)
> 
> 
> Well, I find the DOS-ish '/' separator much nastier than '-' options. 

The `/' would most likely have come from VMS or a precursor.  VMS has 
[had?] a remarkably well structured (too well structured?) CLI interface 
(I show my heritage :-).

> A question of personal taste.  ``log'' unfortunately is more like
> ``tee'' than it is like redirection; how about a simple ``redirect''
> command?
> 
>   redirect [-a[ppend]] FILE [COMMAND]
>   log [-a[ppend]] FILE [COMMAND]

Or `log/a FILE [COMMAND]'  or, hmm, something like:

	set log write FILE
	set log redirect FILE
	set log append FILE
	show log

and

	log[/a] FILE command-that-isn't-optional

Same for redirect.

Are you proposing that ``print/FMT'' gets replaced by ``print -FMT''. 
There shouldn't be two conflicting syntaxes.

Andrew

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Thu, Jul 25, 2002 at 01:36:29PM -0400, Andrew Cagney wrote:
> >I think this was raised before (fernando and I discussed it somewhere on 
> >>gdb@).  GDB is used on systems that are not even UNIX like (namely 
> >>DJGPP), trying to tie the syntax to UNIX is such a good idea.  GDB needs 
> >>a syntax spec, the current piece meal aproach is regrettable :-(
> >>
> >>If the command was called ``log'' rather than ``tee'' then I don't think 
> >>we would have problems with ``log -a''.  (I'm not saying that log is the 
> >>right name mind.)
> >
> >
> >Well, I find the DOS-ish '/' separator much nastier than '-' options. 
> 
> The `/' would most likely have come from VMS or a precursor.  VMS has 
> [had?] a remarkably well structured (too well structured?) CLI interface 
> (I show my heritage :-).

Before my day :)

> >A question of personal taste.  ``log'' unfortunately is more like
> >``tee'' than it is like redirection; how about a simple ``redirect''
> >command?
> >
> >  redirect [-a[ppend]] FILE [COMMAND]
> >  log [-a[ppend]] FILE [COMMAND]
> 
> Or `log/a FILE [COMMAND]'  or, hmm, something like:
> 
> 	set log write FILE
> 	set log redirect FILE
> 	set log append FILE
> 	show log
> 
> and
> 
> 	log[/a] FILE command-that-isn't-optional
> 
> Same for redirect.

I don't know about that... write/redirect/append aren't really mutually
exclusive (it's overwrite/append and redirect/tee), and that doesn't
mesh with the feeling of a set command.

> Are you proposing that ``print/FMT'' gets replaced by ``print -FMT''. 
> There shouldn't be two conflicting syntaxes.

Well, I don't have a problem with reserving / for FMT sequences
(anything that modifies how output is printed) and - for options
(anything that modifies what gets done).  I think '/' is only used for
format sequences right now; at least I don't see anything otherwise in
the manual besides display, print, and x.  Heck, I actually think
separating format specifiers and options this way is intuitive.


So in other words, I'd like to stick with 
> >  redirect [-a[ppend]] FILE [COMMAND]
> >  log [-a[ppend]] FILE [COMMAND]

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

> So in other words, I'd like to stick with 
> 
>> >  redirect [-a[ppend]] FILE [COMMAND]
>> >  log [-a[ppend]] FILE [COMMAND]

Don't forget that prefix `-' and `--' are valid C operators.  You can't 
tell the difference between the above and a valid C expressions.  I 
think that rules `-...' out.

I also think it should be part of the ``set'' family.  I think it is 
entirely reasonable for a user to type:
	``show logfile''
set/show can be used in ways that avoid the need for parameters.

enjoy,
Andrew

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Tue, Jul 30, 2002 at 11:25:25PM -0400, Andrew Cagney wrote:
> >So in other words, I'd like to stick with 
> >
> >>>  redirect [-a[ppend]] FILE [COMMAND]
> >>>  log [-a[ppend]] FILE [COMMAND]
> 
> Don't forget that prefix `-' and `--' are valid C operators.  You can't 
> tell the difference between the above and a valid C expressions.  I 
> think that rules `-...' out.

Actually, I still disagree - I think that it remains unambiguous where
to expect an expression and where to expect command-line syntax. 
However, I am interested in finishing this patch, not in continuing a
debate about the command-line syntax, which I don't have time to do at
the moment.  So...

> I also think it should be part of the ``set'' family.  I think it is 
> entirely reasonable for a user to type:
> 	``show logfile''
> set/show can be used in ways that avoid the need for parameters.

Perhaps
  set logging redirect append FILE
  set logging log overwrite FILE
  log log overwrite FILE COMMAND
but "log log" is very unintuitive.

The problem is that now the syntax is very verbose, and I believe much
more complicated than it needs to be.  I really like the one above,
which I keep suggesting, which is not incompatible with "show logging".

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

> On Tue, Jul 30, 2002 at 11:25:25PM -0400, Andrew Cagney wrote:
> 
>> >So in other words, I'd like to stick with 
>> >
> 
>> >>>  redirect [-a[ppend]] FILE [COMMAND]
>> >>>  log [-a[ppend]] FILE [COMMAND]
> 
>> 
>> Don't forget that prefix `-' and `--' are valid C operators.  You can't 
>> tell the difference between the above and a valid C expressions.  I 
>> think that rules `-...' out.
> 
> 
> Actually, I still disagree - I think that it remains unambiguous where
> to expect an expression and where to expect command-line syntax. 

It becomes context depedent :-(  Do we use ``/'' when an expression is 
the first parameter but ``-'' when a file is the first parameter ....?

Andrew

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Tue, Jul 30, 2002 at 11:51:28PM -0400, Andrew Cagney wrote:
> >On Tue, Jul 30, 2002 at 11:25:25PM -0400, Andrew Cagney wrote:
> >
> >>>So in other words, I'd like to stick with 
> >>>
> >
> >>>>>  redirect [-a[ppend]] FILE [COMMAND]
> >>>>>  log [-a[ppend]] FILE [COMMAND]
> >
> >>
> >>Don't forget that prefix `-' and `--' are valid C operators.  You can't 
> >>tell the difference between the above and a valid C expressions.  I 
> >>think that rules `-...' out.
> >
> >
> >Actually, I still disagree - I think that it remains unambiguous where
> >to expect an expression and where to expect command-line syntax. 
> 
> It becomes context depedent :-(  Do we use ``/'' when an expression is 
> the first parameter but ``-'' when a file is the first parameter ....?

No, we use ``/'' for print formatting characters and ``-'' for options. 
Which appears to be exactly the status quo.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[david carlton]

On Tue, 30 Jul 2002 23:25:25 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

>> So in other words, I'd like to stick with 
>> 
>>> >  redirect [-a[ppend]] FILE [COMMAND]
>>> >  log [-a[ppend]] FILE [COMMAND]

> Don't forget that prefix `-' and `--' are valid C operators.  You
> can't tell the difference between the above and a valid C
> expressions.  I think that rules `-...' out.

It makes '-...' undesirable, but I don't think it rules it out.  Yes,
there are situations where what had previously been a legitimate print
statement now becomes either a syntax error or, worse yet, remains
legitimate but with a different meaning.  But I doubt they are all
_that_ common, and there is an easy workaround once you're aware of
this problem, namely enclosing your expression in parentheses.

The reason why I don't think they're all that common is that I don't
think that it's all that common to want to print the value of an
expression starting with a unary minus.  I don't think I'd do that
very frequently in everyday interactive use: even if the value that I
happen to care about is -something, I'd probably just do 'p something'
and negate the answer mentally.  I find it easier to imagine printing
an expression that begins with a unary minus if that print command is
run automatically when hitting a breakpoint, but even there I doubt it
would be too uncommon.

And, furthermore, it only breaks code where the next character after
the unary - is one of the formatting symbols and the character after
that is whitespace.  (So the fact that '--' is a valid C operator
isn't so relevant, because '-' isn't a formatting character.  Good
thing, too, because I print expressions starting with '--' more often
than ones starting just with '-'.)  Unfortunately, some of the
formatting symbols are common variable names - probably '-x' would be
the most common clash - but even so I'm sure that, the vast majority
of the time an expression starts with a unary minus, the unary minus
is unambiguously part of the expression.

And it seems to me that it isn't so big a problem when previously
valid print statements become syntax errors: in those situations, the
user at least is aware that something's wrong, and can insert
parentheses to solve the problem.  Situations where previously valid
print statements remain valid but have their meaning changed are more
problematic; but those are even more rare.  Sure, there are some
examples - 'p -x - 3' is one (though 'p -x-3' isn't, or 'p (-x) - 3')
- but they're not at all common.

So I think that, if this syntax is changed, the fact that expressions
could start with unary minus signs is going to cause much less
grumbling from users than the fact that, once the old p/x syntax gets
obsoleted, they'll have to convert over to typing p -x instead.

David Carlton
carlton@math.stanford.edu

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Wed, Jul 31, 2002 at 09:32:19AM -0700, david carlton wrote:
> So I think that, if this syntax is changed, the fact that expressions
> could start with unary minus signs is going to cause much less
> grumbling from users than the fact that, once the old p/x syntax gets
> obsoleted, they'll have to convert over to typing p -x instead.

Which, for the record, I never suggested - I think p/x and log -a are
different enough uses of options that they can still both exist without
any real inconsistency.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: >, >>, and "tee" operators

[Andrew Cagney]

> On Wed, Jul 31, 2002 at 09:32:19AM -0700, david carlton wrote:
> 
>> So I think that, if this syntax is changed, the fact that expressions
>> could start with unary minus signs is going to cause much less
>> grumbling from users than the fact that, once the old p/x syntax gets
>> obsoleted, they'll have to convert over to typing p -x instead.

DanielJ wrote:

> Which, for the record, I never suggested - I think p/x and log -a are
> different enough uses of options that they can still both exist without
> any real inconsistency.

``log -a'' works because it is ``log -a FILE''.  A leading ``-'' in a 
file name on VMS, DOS and UNIX is very unlikely.

Problems arise when this same syntax is applied to a command that takes 
an expression:

	command -OPTION EXPRESSION

There, as DavidC noted, there is a conflict.  I think the reason (note 
I'm guessing) the ``/'' character was chosen for print et.al. was 
because it didn't conflict with any known expression.

> Don't forget that prefix `-' and `--' are valid C operators.  You
>> can't tell the difference between the above and a valid C
>> expressions.  I think that rules `-...' out.
> 
> 
> It makes '-...' undesirable, but I don't think it rules it out.  Yes,
> there are situations where what had previously been a legitimate print
> statement now becomes either a syntax error or, worse yet, remains
> legitimate but with a different meaning.  But I doubt they are all
> _that_ common, and there is an easy workaround once you're aware of
> this problem, namely enclosing your expression in parentheses.

There is an old rule ``KISS''.  At some point there are too many 
workarounds and edge cases and they are arising too frequently.

To consider a working example, the MI uses ``-''.  The syntax is loose 
enough to allow humans to enter free form commands vis:
	-mi-command -opt optarg param
However, client programs should always generate commands using the more 
robust form:
	-mi-command -opt "optarg" -- "param"
(always include ``--'', encode all parameters as quoted strings.)

--

BTW, simply adding paren around an expression doesn't really help.  GDB 
often parses expressions and files using ``strchr(' ')''.  That means 
that things like:

	EXPRESSION: ("foo bar")
	FILE: "/a b/c"

do not get handled correctly.

Andrew

Re: RFA: >, >>, and "tee" operators

[david carlton]

On Thu, 01 Aug 2002 11:05:28 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

[ In response to my comment that the 'print -x EXPRESSION' syntax
didn't break many cases and those case could be fixed with adding
parentheses. ]

> There is an old rule ``KISS''.  At some point there are too many 
> workarounds and edge cases and they are arising too frequently.

Yes, that's true.  But keeping things simple has several implications
here:

1) Option syntax should be uniform between programs.
2) Option syntax should be uniform within a single program.
3) Option syntax should be chosen so as to make it clear when
   something is an option and when something isn't.

Point 1) suggests that option syntax should start with -.  (Or perhaps
with - in a Unix environment and / in other appropriate environments.)
Point 2) suggests that all options should start the same way.  Point
3) suggests that option syntax shouldn't start with -.  (Incidentally,
are there programming languages in which / can be a unary operator?
Not that I'm suggesting we should seriously worry about that, I'm just
curious.)  But, as we've all noticed, these are incompatible.

Daniel suggests that bending 2) to the extent that GDB does is
acceptable.  I suggest that bending 3) might be acceptable, or at any
rate isn't clearly less acceptable than bending 2).  I'm not sure
which one you want to bend, or if you see another way out of this
problem; you seem strongly against bending 2) or 3), but I doubt that
bending 1) would make too many people happy either.

> To consider a working example, the MI uses ``-''.  The syntax is loose 
> enough to allow humans to enter free form commands vis:
> 	-mi-command -opt optarg param
> However, client programs should always generate commands using the more 
> robust form:
> 	-mi-command -opt "optarg" -- "param"
> (always include ``--'', encode all parameters as quoted strings.)

Indeed.  And I claim that programs that need to use the print command
in a robust way could simply do
  print (EXPRESSION)
rather than
  print EXPRESSION

As you say, this adds another special case to consider; I agree that
this is unfortunate, and would be avoided in a perfect world.

> BTW, simply adding paren around an expression doesn't really help.
> GDB often parses expressions and files using ``strchr(' ')''.  That
> means that things like:

> 	EXPRESSION: ("foo bar")
> 	FILE: "/a b/c"

> do not get handled correctly.

I'm admittedly not an expert about how GDB parses expressions, but I
don't really see the relevance here.  I'm not claiming that adding
parentheses will solve other existing problems with the GDB parser;
but are there really situations where GDB would parse EXPRESSION
correctly but (EXPRESSION) incorrectly?  (Here, by EXPRESSION I mean
"expression in the language that we're debugging", of course.)  I
can't reproduce the problem you mention above:

(gdb) p "foo bar"
$2 = "foo bar"
(gdb) p ("foo bar")
$3 = "foo bar"
(gdb) p ("foo bar"[4])
$4 = 98 'b'

but I would imagine that, if there are situations where GDB handles
("foo bar") incorrectly, it would also handle "foo bar" incorrectly.

Of course, this is all a bit academic now: it seems that people agree
that, for commands that take filenames, using - to start options is
reasonable, which answers the immediate question that started the
thread.

David Carlton
carlton@math.stanford.edu

Re: RFA: >, >>, and "tee" operators

[Daniel Jacobowitz]

On Thu, Aug 01, 2002 at 10:24:54AM -0700, david carlton wrote:
> On Thu, 01 Aug 2002 11:05:28 -0400, Andrew Cagney
> <ac131313@ges.redhat.com> said:
> 
> [ In response to my comment that the 'print -x EXPRESSION' syntax
> didn't break many cases and those case could be fixed with adding
> parentheses. ]
> 
> > There is an old rule ``KISS''.  At some point there are too many 
> > workarounds and edge cases and they are arising too frequently.
> 
> Yes, that's true.  But keeping things simple has several implications
> here:
> 
> 1) Option syntax should be uniform between programs.
> 2) Option syntax should be uniform within a single program.
> 3) Option syntax should be chosen so as to make it clear when
>    something is an option and when something isn't.
> 
> Point 1) suggests that option syntax should start with -.  (Or perhaps
> with - in a Unix environment and / in other appropriate environments.)
> Point 2) suggests that all options should start the same way.  Point
> 3) suggests that option syntax shouldn't start with -.  (Incidentally,
> are there programming languages in which / can be a unary operator?
> Not that I'm suggesting we should seriously worry about that, I'm just
> curious.)  But, as we've all noticed, these are incompatible.
> 
> Daniel suggests that bending 2) to the extent that GDB does is
> acceptable.  I suggest that bending 3) might be acceptable, or at any
> rate isn't clearly less acceptable than bending 2).  I'm not sure
> which one you want to bend, or if you see another way out of this
> problem; you seem strongly against bending 2) or 3), but I doubt that
> bending 1) would make too many people happy either.

> Of course, this is all a bit academic now: it seems that people agree
> that, for commands that take filenames, using - to start options is
> reasonable, which answers the immediate question that started the
> thread.

I'm not sure we really reached that agreement... though I'd be happy if
we had :)

Here's the current version of this patch.  It uses (and documents,
hopefully I got the texinfo right this time):
  redirect [-a] [FILE [COMMAND]]
  log [-a] [FILE [COMMAND]]

Andrew, would you prefer to spend some time discussing command line
syntaxen first?  I'd rather put this in (I think the syntax is right,
as I've explained) and then start trying to draft a command line
overhaul for 6.0.  Formally specify commands, write a less ad-hoc
command line parser and use it in calling commands, etc.

(Is syntaxen a word?)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-08-01  Tom Tromey  <tromey@redhat.com>
	    Daniel Jacobowitz  <drow@mvista.com>

	* cli-out.c (struct ui_out_data): Add original_stream.
	(cli_redirect): New function.
	(cli_ui_out_impl): Add cli_redirect.
	(cli_out_new): Initialize original_stream.
	* ui-out.c (default_ui_out_impl): Add NULL for redirect member.
	(uo_redirect, ui_out_redirect): New.
	* ui-out.h (struct ui_out_impl): Add redirect member.
	(redirect_ftype): New.
	(ui_out_redirect): Add prototype.
	* top.c (redirect_output, log_output, handle_redirections)
	(pop_output_files): New functions.
	(init_main): Create "redirect" and "log" commands.

2002-08-01  Daniel Jacobowitz  <drow@mvista.com>

	* mi-out.c (mi_ui_out_impl): Add NULL for redirect member.

2002-08-01  Daniel Jacobowitz  <drow@mvista.com>

	* tui-out.c (tui_ui_out_impl): Add NULL for redirect member.

2002-08-01  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.texinfo (Redirecting output): New chapter.

Index: cli-out.c
===================================================================
RCS file: /cvs/src/src/gdb/cli-out.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 cli-out.c
--- cli-out.c	19 Mar 2002 02:51:04 -0000	1.14
+++ cli-out.c	1 Aug 2002 18:50:59 -0000
@@ -31,6 +31,7 @@
 struct ui_out_data
   {
     struct ui_file *stream;
+    struct ui_file *original_stream;
     int suppress_output;
   };
 
@@ -63,6 +64,7 @@ static void cli_message (struct ui_out *
 			 const char *format, va_list args);
 static void cli_wrap_hint (struct ui_out *uiout, char *identstring);
 static void cli_flush (struct ui_out *uiout);
+static int cli_redirect (struct ui_out *uiout, struct ui_file *outstream);
 
 /* This is the CLI ui-out implementation functions vector */
 
@@ -86,6 +88,7 @@ static struct ui_out_impl cli_ui_out_imp
   cli_message,
   cli_wrap_hint,
   cli_flush,
+  cli_redirect,
   0, /* Does not need MI hacks (i.e. needs CLI hacks).  */
 };
 
@@ -323,6 +326,24 @@ cli_flush (struct ui_out *uiout)
   gdb_flush (data->stream);
 }
 
+int
+cli_redirect (struct ui_out *uiout, struct ui_file *outstream)
+{
+  struct ui_out_data *data = ui_out_data (uiout);
+  if (outstream != NULL)
+    {
+      data->original_stream = data->stream;
+      data->stream = outstream;
+    }
+  else if (data->original_stream != NULL)
+    {
+      data->stream = data->original_stream;
+      data->original_stream = NULL;
+    }
+
+  return 0;
+}
+
 /* local functions */
 
 /* Like cli_field_fmt, but takes a variable number of args
@@ -361,6 +382,7 @@ cli_out_new (struct ui_file *stream)
 
   struct ui_out_data *data = XMALLOC (struct ui_out_data);
   data->stream = stream;
+  data->original_stream = NULL;
   data->suppress_output = 0;
   return ui_out_new (&cli_ui_out_impl, data, flags);
 }
Index: top.c
===================================================================
RCS file: /cvs/src/src/gdb/top.c,v
retrieving revision 1.65
diff -u -p -u -r1.65 top.c
--- top.c	24 Jul 2002 17:58:46 -0000	1.65
+++ top.c	1 Aug 2002 18:50:59 -0000
@@ -1730,6 +1730,191 @@ dont_repeat_command (char *ignored, int 
 				   necessarily reading from stdin.  */
 }
 \f
+/* Functions and variables for gdb output redirection.  */
+
+/* These hold the pushed copies of the gdb output files.
+   If NULL then nothing has yet been pushed.  */
+static struct ui_file *saved_stdout;
+static struct ui_file *saved_stderr;
+static struct ui_file *saved_stdlog;
+static struct ui_file *saved_stdtarg;
+static char *saved_filename;
+
+/* If we've pushed output files, close them and pop them.  */
+static void
+pop_output_files ()
+{
+  if (saved_stdout != NULL)
+    {
+      xfree (saved_filename);
+      saved_filename = NULL;
+
+      /* Only delete one of the files -- they are all set to the same
+	 value.  */
+      ui_file_delete (gdb_stdout);
+      gdb_stdout = saved_stdout;
+      gdb_stderr = saved_stderr;
+      gdb_stdlog = saved_stdlog;
+      gdb_stdtarg = saved_stdtarg;
+      saved_stdout = NULL;
+      saved_stderr = NULL;
+      saved_stdlog = NULL;
+      saved_stdtarg = NULL;
+
+      ui_out_redirect (uiout, NULL);
+    }
+}
+
+/* This is a helper for the `redirect' and `log' redirection commands.  */
+static void
+handle_redirections (char *command, char *filename, char *mode, int tee,
+		     int from_tty)
+{
+  struct ui_file *output;
+  struct ui_file *tmp_stdout, *tmp_stderr, *tmp_stdlog, *tmp_stdtarg;
+  char *cmd = NULL;
+
+  if (filename == NULL)
+    return;
+
+  if (*filename)
+    {
+      /* Skip whitespace.  */
+      while (*filename && isspace (*filename))
+	filename++;
+
+      /* Skip the filename.  */
+      cmd = filename;
+      while (*cmd && !isspace (*cmd))
+	cmd ++;
+      if (*cmd)
+	*(cmd++) = 0;
+      while (*cmd && isspace (*cmd))
+	cmd ++;
+
+      if (!*cmd)
+	cmd = NULL;
+    }
+
+  if (cmd == NULL)
+    {
+      char *tmp = NULL;
+      if (from_tty && saved_filename != NULL)
+	tmp = xstrdup (saved_filename);
+
+      pop_output_files ();
+
+      if (tmp != NULL)
+	{
+	  fprintf_unfiltered (saved_stdout, "Done redirecting to %s.\n",
+			      saved_filename);
+	  xfree (tmp);
+	}
+    }
+
+  if (*filename == 0)
+    return;
+
+  output = gdb_fopen (filename, mode);
+  if (output == NULL)
+    perror_with_name (command);
+
+  /* Redirects everything to gdb_stdout while this is running.  */
+  if (tee)
+    {
+      output = tee_file_new (gdb_stdout, 0, output, 1);
+      if (output == NULL)
+	perror_with_name (command);
+      if (from_tty && cmd == NULL)
+	fprintf_unfiltered (gdb_stdout, "Copying output to %s.\n", filename);
+    }
+  else if (from_tty && cmd == NULL)
+    fprintf_unfiltered (gdb_stdout, "Redirecting output to %s.\n", filename);
+
+  if (cmd == NULL)
+    {
+      saved_filename = xstrdup (filename);
+      saved_stdout = gdb_stdout;
+      saved_stderr = gdb_stderr;
+      saved_stdlog = gdb_stdlog;
+      saved_stdtarg = gdb_stdtarg;
+    }
+  else
+    {
+      tmp_stdout = gdb_stdout;
+      tmp_stderr = gdb_stderr;
+      tmp_stdlog = gdb_stdlog;
+      tmp_stdtarg = gdb_stdtarg;
+    }
+  
+  gdb_stdout = output;
+  gdb_stderr = output;
+  gdb_stdlog = output;
+  gdb_stdtarg = output;
+  if (ui_out_redirect (uiout, gdb_stdout) < 0)
+    warning ("Current output protocol does not support redirection");
+
+  if (cmd != NULL)
+    {
+      catch_command_errors (execute_command, cmd,
+			    from_tty, RETURN_MASK_ALL);
+
+      /* Only delete one of the files -- they are all set to the same
+	 value.  */
+      ui_file_delete (gdb_stdout);
+
+      gdb_stdout = tmp_stdout;
+      gdb_stderr = tmp_stderr;
+      gdb_stdlog = tmp_stdlog;
+      gdb_stdtarg = tmp_stdtarg;
+      if (saved_filename)
+	ui_out_redirect (uiout, gdb_stdout);
+      else
+	ui_out_redirect (uiout, NULL);
+    }
+}
+
+/* Redirect output to a file.  */
+static void
+redirect_output (char *args, int from_tty)
+{
+  if (args)
+    {
+      /* Check for "-a".  */
+      while (*args && isspace (*args))
+	++args;
+
+      if (args[0] == '-' && args[1] == 'a' && isspace (args[2]))
+	{
+	  handle_redirections ("redirect", args + 3, "a", 0, from_tty);
+	  return;
+	}
+    }
+
+  handle_redirections ("redirect", args, "w", 0, from_tty);
+}
+
+/* Redirect output by writing to a file and writing to the screen.  */
+static void
+log_output (char *args, int from_tty)
+{
+  if (args)
+    {
+      /* Check for "-a".  */
+      while (*args && isspace (*args))
+	++args;
+
+      if (args[0] == '-' && args[1] == 'a' && isspace (args[2]))
+	{
+	  handle_redirections ("log", args + 3, "a", 1, from_tty);
+	  return;
+	}
+    }
+
+  handle_redirections ("log", args, "w", 1, from_tty);
+}
+
+\f
 /* Functions to manipulate command line editing control variables.  */
 
 /* Number of commands to print in each call to show_commands.  */
@@ -2063,6 +2248,15 @@ ie. the number of previous commands to k
 Use \"on\" to enable the notification, and \"off\" to disable it.", &setlist),
 	 &showlist);
     }
+
+  add_com ("redirect", no_class, redirect_output,
+	   "Redirect further gdb output to a file.\n\
+If \"-a\" is specified append to the file; otherwise overwrite it.\n\
+If no filename is given, any previous redirection is stopped.");
+  add_com ("log", no_class, log_output,
+	   "Send further gdb output to both the terminal and a file.\n\
+If \"-a\" is specified append to the file; otherwise overwrite it.\n\
+If no filename is given, any previous redirection is stopped.");
 }
 
 void
Index: ui-out.c
===================================================================
RCS file: /cvs/src/src/gdb/ui-out.c,v
retrieving revision 1.23
diff -u -p -u -r1.23 ui-out.c
--- ui-out.c	27 Jul 2002 01:54:15 -0000	1.23
+++ ui-out.c	1 Aug 2002 18:50:59 -0000
@@ -206,6 +206,7 @@ struct ui_out_impl default_ui_out_impl =
   default_message,
   default_wrap_hint,
   default_flush,
+  NULL,
   0, /* Does not need MI hacks.  */
 };
 
@@ -254,6 +255,7 @@ static void uo_message (struct ui_out *u
 			const char *format, va_list args);
 static void uo_wrap_hint (struct ui_out *uiout, char *identstring);
 static void uo_flush (struct ui_out *uiout);
+static int uo_redirect (struct ui_out *uiout, struct ui_file *outstream);
 
 /* Prototypes for local functions */
 
@@ -639,6 +641,12 @@ ui_out_flush (struct ui_out *uiout)
   uo_flush (uiout);
 }
 
+int
+ui_out_redirect (struct ui_out *uiout, struct ui_file *outstream)
+{
+  uo_redirect (uiout, outstream);
+}
+
 /* set the flags specified by the mask given */
 int
 ui_out_set_flags (struct ui_out *uiout, int mask)
@@ -980,6 +988,14 @@ uo_flush (struct ui_out *uiout)
   if (!uiout->impl->flush)
     return;
   uiout->impl->flush (uiout);
+}
+
+int
+uo_redirect (struct ui_out *uiout, struct ui_file *outstream)
+{
+  if (!uiout->impl->redirect)
+    return -1;
+  uiout->impl->redirect (uiout, outstream);
 }
 
 /* local functions */
Index: ui-out.h
===================================================================
RCS file: /cvs/src/src/gdb/ui-out.h,v
retrieving revision 1.15
diff -u -p -u -r1.15 ui-out.h
--- ui-out.h	6 Jul 2001 03:53:11 -0000	1.15
+++ ui-out.h	1 Aug 2002 18:50:59 -0000
@@ -237,6 +237,8 @@ typedef void (message_ftype) (struct ui_
 			      const char *format, va_list args);
 typedef void (wrap_hint_ftype) (struct ui_out * uiout, char *identstring);
 typedef void (flush_ftype) (struct ui_out * uiout);
+typedef int (redirect_ftype) (struct ui_out * uiout,
+			      struct ui_file * outstream);
 
 /* ui-out-impl */
 
@@ -260,6 +262,7 @@ struct ui_out_impl
     message_ftype *message;
     wrap_hint_ftype *wrap_hint;
     flush_ftype *flush;
+    redirect_ftype *redirect;
     int is_mi_like_p;
   };
 
@@ -271,5 +274,9 @@ extern struct ui_out_data *ui_out_data (
 extern struct ui_out *ui_out_new (struct ui_out_impl *impl,
 				  struct ui_out_data *data,
 				  int flags);
+
+/* Redirect the ouptut of a ui_out object temporarily.  */
+
+extern int ui_out_redirect (struct ui_out *uiout, struct ui_file *outstream);
 
 #endif /* UI_OUT_H */
Index: cli/cli-decode.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-decode.c,v
retrieving revision 1.28
diff -u -p -u -r1.28 cli-decode.c
--- cli/cli-decode.c	30 Jul 2002 13:45:14 -0000	1.28
+++ cli/cli-decode.c	1 Aug 2002 18:51:00 -0000
@@ -924,7 +924,7 @@ lookup_cmd_1 (char **text, struct cmd_li
      so that "set args_foo()" doesn't get interpreted as
      "set args _foo()".  */
   for (p = *text;
-       *p && (isalnum (*p) || *p == '-' || *p == '_' ||
+       *p && (isalnum (*p) || *p == '-' || *p == '_' || 
 	      (tui_version &&
 	       (*p == '+' || *p == '<' || *p == '>' || *p == '$')) ||
 	      (xdb_commands && (*p == '!' || *p == '/' || *p == '?')));
Index: mi/mi-out.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-out.c,v
retrieving revision 1.23
diff -u -p -u -r1.23 mi-out.c
--- mi/mi-out.c	19 Mar 2002 02:51:08 -0000	1.23
+++ mi/mi-out.c	1 Aug 2002 18:51:04 -0000
@@ -85,6 +85,7 @@ struct ui_out_impl mi_ui_out_impl =
   mi_message,
   mi_wrap_hint,
   mi_flush,
+  NULL,
   1, /* Needs MI hacks.  */
 };
 
Index: tui/tui-out.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui-out.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 tui-out.c
--- tui/tui-out.c	19 Mar 2002 02:51:09 -0000	1.2
+++ tui/tui-out.c	1 Aug 2002 18:51:04 -0000
@@ -88,6 +88,7 @@ static struct ui_out_impl tui_ui_out_imp
   tui_message,
   tui_wrap_hint,
   tui_flush,
+  NULL,
   0, /* Does not need MI hacks (i.e. needs CLI hacks).  */
 };
 
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.105
diff -u -p -r1.105 gdb.texinfo
--- doc/gdb.texinfo	24 Jul 2002 23:51:36 -0000	1.105
+++ doc/gdb.texinfo	1 Aug 2002 18:58:16 -0000
@@ -752,6 +752,7 @@ type @kbd{quit} or @kbd{C-d} to exit.
 * Invoking GDB::                How to start @value{GDBN}
 * Quitting GDB::                How to quit @value{GDBN}
 * Shell Commands::              How to use shell commands inside @value{GDBN}
+* Redirecting output::          How to redirect @value{GDBN}'s output to files
 @end menu
 
 @node Invoking GDB
@@ -1201,6 +1202,26 @@ You do not have to use the @code{shell} 
 Execute the @code{make} program with the specified
 arguments.  This is equivalent to @samp{shell make @var{make-args}}.
 @end table
+
+@node Redirecting output
+@section Redirecting output
+
+You may want to save the output of @value{GDBN} commands to a file.
+There are three commands to control @value{GDBN}'s logging.
+
+@table @code
+@kindex redirect
+@item redirect [-a] [@var{file} [@var{command}]]
+Redirect all output to @var{file}.
+@kindex log
+@item log [-a] [@var{file} [@var{command}]]
+Copy output to both the screen and @var{file}.
+@end table
+
+Both @code{redirect} and @code{log} default to overwriting the log file,
+unless @code{-a} is specified.  You may start redirection by specifying
+just @var{file}, end redirection by not specifying @var{file}, and redirect
+the output of only one command by specifying @var{command} after the filename.
 
 @node Commands
 @chapter @value{GDBN} Commands

Re: RFA: >, >>, and "tee" operators

[david carlton]

On Thu, 1 Aug 2002 15:03:48 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> +@table @code
> +@kindex redirect
> +@item redirect [-a] [@var{file} [@var{command}]]
> +Redirect all output to @var{file}.
> +@kindex log
> +@item log [-a] [@var{file} [@var{command}]]
> +Copy output to both the screen and @var{file}.
> +@end table
> +
> +Both @code{redirect} and @code{log} default to overwriting the log file,
> +unless @code{-a} is specified.

Personally, I'd say

  Both @code{redirect} and @code{log} default to overwriting
  $var{file} unless @code{-a} is specified, in which case they append
  to $var{file}.

So two changes: replace "the log file" with "$var{file}" (after all,
is it really a log file if you're using redirect instead of log?), and
make it a bit more explicit what the alternate behaviour is, just in
case the person reading the documentation hasn't gotten much sleep
recently.  (And I guess I deleted a comma as well, for better or for
worse: I like the comma in your version but don't like once the bit
about appending is added.)

Incidentally, I hope I'm not being out-of-place in making comments
like this or my earlier ones about syntax; I realize that I'm new to
this list and have comparatively little experience with GDB.  I
certainly wouldn't comment on matters internal to GDB without more
experience than I have now.

David Carlton
carlton@math.stanford.edu

Re: RFA: >, >>, and "tee" operators

[Fernando Nasser]

Daniel Jacobowitz wrote:
> 
> GDB's option identifier varies, actually; symbol-file -readnow,
> add-symbol-file -s <section> <address> are the only two I see offhand.
> We only use / for print format characters.  Mostly we just drop them
> all on one line.
> 

That went in by mistake (it was before my time anyway).  Not that I have
anything against it (see below).

> Well, I don't have a problem with reserving / for FMT sequences
> (anything that modifies how output is printed) and - for options
> (anything that modifies what gets done).  I think '/' is only used for
> format sequences right now; at least I don't see anything otherwise in
> the manual besides display, print, and x.  Heck, I actually think
> separating format specifiers and options this way is intuitive.

That was exactly my argument years ago.  But I lost it (well, actually
the discussion went on and on for weeks without anyone reaching an
agreement and I gave up on the idea).


I don't see much problem in using the set commands (and thus avoinding
this issue).  It also has its advantages like a show comand.
Besides, set/show commands are there for things that alter GDB's 
behavior -- in the case, where output is sent.


What is the current option being defended?


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9