Whenever wtokensplit is used to split into argv/argc, it's better to
use the built-in function wtokenfree() as a wfree call only on argv
is not freeing the memory properly.
This patch removes the format-truncation warning. The problem is because buf and comm are arrays with the same size (PATH_MAX). In the snprintf, comm is copied to buf, more some extra characters. The patch reduces the size for the array comm in the extra characters. Without the patch, the comm array is truncated. With the patch, the same characters are copied, without the warning.
wmgenmenu.c: In function ‘find_and_write’:
wmgenmenu.c:436:41: warning: ‘snprintf’ output may be truncated before the last format character [-Wformat-truncation=]
snprintf(buf, sizeof(buf), "%s -e %s", terminal ? terminal : "xterm" , comm);
^
wmgenmenu.c:436:5: note: ‘snprintf’ output 5 or more bytes (assuming 4105) into a destination of size 4104
snprintf(buf, sizeof(buf), "%s -e %s", terminal ? terminal : "xterm" , comm);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Rodolfo García Peñas (kix) <kix@kix.es>
As reported by Milan Čermák, using this variable breaks compilation on
Solaris, because it is a hack which is not standard. To ensure portability,
we now rely on main's argv[0] which is always available.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
When a command is given for a menu to be run through a terminal, there is
a piece of code that removes everything from a '!' to the end of the line.
The original code was too dense and not really optimal, so this patch
proposes a more explicit code, mainly for maintainability.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As pointed by Coverity, the buffer used to store the command for the menu
has a fixed size, so a check is welcome to avoid buffer overflow.
Signed-off-by: Christophe CURIS <christophe.curis@free.fr>
As reported by Shawn W Dunn, the configuration strings written by wmgenmenu
in $HOME/GNUstep/Defaults/WMRootMenu were not reflecting his installation
directories choices.
Fix this by writing strings composed with PKGDATADIR.
Dario Niedermann reported on 27.11.2011:
Selecting "Save Theme" from WMaker's root menu results in dialog box
asking for theme name, but then nothing is saved.
This feature used to work in 0.92.0.
and the reason for it (if he uses a WMRootMenu generated by wmgenmenu) is
the incorrect use of the option "-t" instead of "-p" to getstyle.
Furthermore, let the invocation of getstyle reflect the new default location
for the themes.
* Remove assigned but not used variables (GCC 4.6)
* Bump _XOPEN_SOURCE to 600, ridding of FreeBSD warnings (this probably need
to be tweaked on a per-implementation basis as problems arise)
- change some variable names to better reflect their purpose, do a little
write-up how a menu is built
- auto-detect what terminal to use for apps in need of a terminal
- fix the chunk that adds the terminal-based apps
* Remove directly include of <libintl.h> and include src/wconfig.h, that
already include libintl.h and declare _() function
* Replace some gettext() calls to _()
These changes fixes build with LINGUAS is unset, and removes I18N
support in this case.
The inspiration comes from Geir T. Kristiansen's 'genmenu' shell script
(http://gtk.no/genmenu) which I have been hapilly using for
the last 9 years or so.
That script generates the Window Maker menu by asking a few questions
and checks whether the applications in a predefined list exist in
the user's $PATH, so that the menu contains only the applications
which are guaranteed to exist and which the user cares about.
However I always thought it was a bit slow to finish, even
when having a file containing the answers to the questions to
be piped in.
And as Kristiansen states in his webpage, his script does not
support internationalization:
"If you want internationalization I really suggest you rewrite
genmenu from scratch anyway in a more sensible language and remove
other limitations while you are at it."
so I decided to rewrite in C and make it support internationalization
(only English and German so far). While I am not sure yet if I removed
"other limitations while you are at it" I definitely made it finish faster.
This C program does not make you questions though.
But in the same spirit as the author of 'genmenu', who says:
"Genmenu is a hack, deal with it, it just happens to serve my needs."
I present you 'wmgenmenu', which you can use like this:
wmgenmenu > /home/mafra/GNUstep/Defaults/WMRootMenu
and the menu is automatically generated from the list of
predefined apps which are contained in the C sources (wmgenmenu.h).
And when you generate the WMRootMenu as above, wmaker will automatically
load the new menu for you (due to the 'inotify' mechanism in wmaker-crm).
As for 'wmgenmenu' being faster than 'genmenu':
[mafra@Pilar:~]$ time ./genmenu.sh < answers.txt &> /dev/null
real 0m3.626s
user 0m0.968s
sys 0m1.830s
[mafra@Pilar:~]$ time wmgenmenu &> /dev/null
real 0m0.020s
user 0m0.006s
sys 0m0.013s
