Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: jur on December 30, 2009, 02:56:37 AM
-
Error on fetch of /mnt/sda7/tce/wpa-supplicant.tcz.md5.txt
Could be a network issue or ...
that this extension has a new name or is no longer supported!
-
Renamed to wpa_supplicant
-
Renaming extensions should occur only when absolutely necessary, as it breaks appsaudit and the integrity of existing tce installations. If the original package is appname-lib, it should be changed to appname_lib upon the next upgrade of the extension. I personally prefer dashes rather than underscores, but the important thing is to stick with whichever the extension was originally named with.
-
You have made a number of other things standard.
Why not make this standard too?
Decide whether all extensions should use dashes or underscores, and whatever is decided, all new extensions can then be named that way. At some appropriate time, existing extensions can be renamed to comply.
-
My apologies if I inconvenienced users with the name change, but after having completely missed the presence of the berkeley db due to the extension name not matching the source package name, I thought it better to rename the wpa_supplicant extension to match the source package name when it was updated.
-
Personally, I don't see much gain in eliminating underscores, since they are used slightly differently (in place of spaces) then hyphens. Standardizing deps/dep, eliminating tcz?, tce extensions are a different
issue IMHO.
-
I guess it is kind of a catch-22, between preserving the upstream source name and standardizing on either dash or underscore. I have harped on preserving upstream source names, which in general I think is a good idea. But maybe we can perserve the upstream names except for using dash instead of underscore for the ease of standardization.
My preference would be to deviate from source names to use dash instead of underscore, which would make it easier for remembering extension names. If the dep file had these extensions in it a dash makes creating the dep file simpler and less prone to typos:
wpa-supplicant.tcz
gcc-lib.tcz
smallbasic-cli.tcz
docbook-xsl.tcz
gtk2-locale.tcz
gs-common-8.70.tcz
As opposed to:
wpa_supplicant.tcz
gcc_lib.tcz
bash-locale.tcz
gtk2_locale.tcz
docbook_xsl.tcz
gc_common-8.70.tcz
gtk-engines.tcz
gtk2_prefs.tcz
I made up some names in the latter to make a point, but using dash in all cases would further simplify the naming structure.
The naming structure has been a work in progress since the beginning, and we have been living and learning along the way. When the repo consisted of about 100 extensions, and there was no updating functions, or boot time dep processing, we didn't need to be very particular over the deatails that make a difference now. But the dash vs underscore has to be one of the last details left to work out.
When we move extensions to the 3.0 repo, the exsiting ones can be brought into compliance.
-
Another thing to think about with standardization is program names. If you look at the application names in the menu, some start with small letters, some start with a capital letter, some are all capitals. It would be nice if there was some uniformity.
-
Thats a good point.
Lower cases, dash to seperate, and otherwise preserving upstream package naming would make things pretty uniform. It may sound like being overly particular, but it would only make life easier.
-
Is it possible to have spaces in names with more than one word in the menu?
-
Spaces in the menu items seem to work ok in the WM's I am familiar with.
-
I would strongly discourage using spaces in any file or directory name on a nix system. The default window manger uses directory and file names for it menu.
-
Using dash '-' versus underscore '_' gives much different results when using grep -w. Apparently dash is treated as whitespace while underscore is not.
-
Oops, forgot about the directory based menu with flwm. So even if some WM's accommodate spaces in menu names, menu entries should work with every WM, especially the default one.
And I was unaware of the dash vs underscore issue with grep. If grep works better with underscore, we could standardize on underscore.
-
Oops, forgot about the directory based menu with flwm. So even if some WM's accommodate spaces in menu names, menu entries should work with every WM, especially the default one.
And I was unaware of the dash vs underscore issue with grep. If grep works better with underscore, we could standardize on underscore.
Underscores are different than hyphens, so get treated differently. Scripts need to check for naming discrepancies anyway. I'm not against simplification, but would be cautious about overdoing it.
-
The point is that if the two are treated differently by grep and such, then one would be preferred over the other. And if whitespace is not desired, that sounds like a dash is not the more friendly for base and other functions.
The fact that the two are treated differently is all the more reason to standardize.
-
Whilst I'm always aghast when coming accross a space in a file name, I strongly believe we should allow for both dash and underscore (with a slight preference for the former).
I can't imagine a situation were 'grep -w' will really be an issue, that could not be avoided by a more suitable regular expression. We should not restrict ourselves too much in our choice of extension names due to (possibly historic) border cases of pattern matching. If it would be a real issue something would be broken now since our extension names are currently using both of them.
I believe to posses a fairly good grasp of regular expressions and their subtle differences when used in conjunction with the likes of grep, sed, vi, perl, ... I've avoided the use of 'grep -w' since those regular expressions might not be easily re-used with another tool.
I also had a quick look accross /usr/sbin, /usr/bin, and /etc/init.d and found only these two uses of 'grep -w':
/usr/bin/tce-load:81: if [ -e "$FROMWHERE"/copy2fs.flg ] || grep -qw $APPNAME "$FROMWHERE"/copy2fs.lst 2>/dev/null; then
/etc/init.d/rc.shutdown:32: if grep -w "$APP" "$LIST" >/dev/null 2>&1; then sed -i '/'"$APP"'/d' "$LIST"; fi
I can't right now see a reason to use 'grep -w' in either case, but I'm sure that there must be a good reason. Nevertheless I'm confident that the same effect can be achieved by some other way. I consider finding properly matching regular expressions an enjoyable brain teaser (maybe like some other folks solve crossword puzzle) and like to humbly offer my skills to find an alternative.
As I minor improvement I'd like to suggest to enclose the pattern in line 81 of tce-load in double-quotes. It's just a habit of mine due to have been bitten on this one a few times when I was less experienced.
-
It was not until recently that we even had regular expression support in the base.
Base programs cannot use extensions to support base infrastructure.
There is always many ways to perform a task. Everyone has their preference.
I rarely comment on the many scripts posted in the forums.
Not everyone who wishes to script process extensions should be required to use regular expressions.