This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch+7.5] auto-load: User conveniences suggested by Doug Evans


On Tue, 21 Aug 2012 19:50:25 +0200, Eli Zaretskii wrote:
> > +  if (!advice_printed)
> > +    {
> > +      const char *homedir = getenv ("HOME");
> > +      char *homeinit;
> > +
> > +      if (homedir == NULL)
> > +	homedir = "$HOME";
> 
> This should fall back on $USERPROFILE or on $APPDATA on MS-Windows if
> $HOME is not defined.  $USERPROFILE/$APPDATA are Windows equivalents
> of $HOME, but some Windows users (including yours truly) set $HOME to
> another directory (e.g., I don't like having my precious files on a
> system disk, because disasters strike there more frequently).

GDB main.c get_init_files does just:
	homedir = getenv ("HOME");

So if getenv ("HOME") does not work GDB will not find such .gdbinit file
anyway.  GDB maybe should do on MS-Windows also getenv ("USERPROFILE") etc.
but that is an unrelated issue needing a fix in main.c get_init_files first.

That part
	if (homedir == NULL)
	  homedir = "$HOME";

may apply for MinGW but it tries to suggest you should 'set HOME c:\' for
example first.  It is very MinGW specific problem.  Any change here without
change in main.c get_init_files does not make sense.


> > +      printf_filtered (_("\
> > +To enable execution of this file add \"add-auto-load-safe-path %s\" \
> > +line to \"%s\".\n\
> 
> Suggest to move the "add-auto-load-safe-path" part to a new line,
> because the file name displayed after that will probably overflow the
> terminal line.

Even the line "add-auto-load-safe-path %s" itself may and will overflow the
terminal line.  I do not find it such a problem, any terminal wraps lines and
most terminals nowadays are several times wider than 80 columns so I do not
think it makes sense to artifically wrap lines for them.  If the user wants
the output more narrow let she narrow her terminal.


> > +  scripts_directory_help = xstrprintf (_("\
> > +Automatically loaded %s%s%sGDB scripts\n\
> > +(named OBJFILE%s) are located in one of the directories listed by this\n\
> > +option.\n\
> > +This option is ignored for the kinds of scripts \
> > +having 'set auto-load ... off'.\n\
> > +Directories listed here need to be present also \
> > +in the 'set auto-load safe-path'\n\
> > +option."),
> 
> Here, the lines are unnecessarily too short, IMO.

I think there should be some clear decision what should the GDB output conform
to.  In this and the paragraph above we have exactly opposite opinions whether
to wrap the text or not.

My opinion:
So far I believe constant text should be formatted to 80 columns, which is
terrible to read but it should conform to GNU Coding Style like the source
does.  But when there is some variable text (%s) contained therein one cannot
expect how the variable text is wide so one can leave it wide enough.


> > -Set the list of directories from which it is safe to auto-load files."), _("\
> > -Show the list of directories from which it is safe to auto-load files."), _("\
> > +Set the list of paths from which it is safe to auto-load files."), _("\
> > +Show the list of paths from which it is safe to auto-load files."), _("\
> 
> Why "paths" instead of directories?  GNU Coding Standards frown on
> using "paths" with this semantics.
> 
> If the problem is that these can be both files and directories,

Yes.

> let's say "list of files and directories that are safe for auto-loading".

OK.  I hope you are fine with "path" in the second part:

-for the 'set auto-load ...' options.  Each directory can be also shell\n\
+for the 'set auto-load ...' options.  Each path entry can be also shell\n\
 wildcard pattern; '*' does not match directory separator.\n\


Thanks,
Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]