Inconsistent parameter expansion
Hello When migrating a shell script from Debian to Ubuntu GNU/Linux, I ran into trouble with parameter expansion being handled differently between bash and dash. The script was originally developed on a FreeBSD box, hence using FreeBSD's bourne shell (not bash nor dash) which is POSIX plus some extra Berkeley extensions (not the same as bash). The idea is that the shell script was supposed to be POSIX and therefore not supposed to fail. After some investigation, I succeeded in locating the problem. > $ for L in A B C D; do mkdir $L && touch $L/FILE; done > $ echo * > A B C D > $ echo */FILE > A/FILE B/FILE C/FILE D/FILE > $ echo *"/FILE" > */FILE > $ I can't figure out why '*/FILE' and '*"/FILE"' are not expanded the same way... Thank you for your lights, Romain -- Romain Tartière <[EMAIL PROTECTED]> HealthGrid SysAdmin pgp: 3BB8 9543 B4F2 3EFA 7478 0BA0 0F8D DB2D B9E4 7019 (ID: 0xB9E47019) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgptkJfA57AJ3.pgp Description: PGP signature
Re: Inconsistent parameter expansion
On Thu, May 15, 2008 at 02:26:02PM +, Romain Tartière wrote:
>
> I can't figure out why '*/FILE' and '*"/FILE"' are not expanded the same
> way...
This is a bug in dash. The following patch should fix the problem,
provided that Ubuntu hasn't built dash with glob(3) enabled because
glob(3) has a similar bug and that needs to be fixed in glibc.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/ChangeLog b/ChangeLog
index 2f65e03..bf9dd4a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2008-05-19 Herbert Xu <[EMAIL PROTECTED]>
+
+ * Fixed non-leading slash treatment in expmeta.
+
2008-05-07 Gerrit Pape <[EMAIL PROTECTED]>
* Fixed lexical error in arithmetic expansion of & and |.
diff --git a/src/expand.c b/src/expand.c
index 2c52781..e4c4c8b 100644
--- a/src/expand.c
+++ b/src/expand.c
@@ -1269,10 +1269,11 @@ expmeta(char *enddir, char *name)
struct dirent *dp;
int atend;
int matchdot;
+ int esc;
metaflag = 0;
start = name;
- for (p = name; *p; p++) {
+ for (p = name; esc = 0, *p; p += esc + 1) {
if (*p == '*' || *p == '?')
metaflag = 1;
else if (*p == '[') {
@@ -1291,11 +1292,11 @@ expmeta(char *enddir, char *name)
}
} else {
if (*p == '\\')
- p++;
- if (*p == '/') {
+ esc++;
+ if (p[esc] == '/') {
if (metaflag)
break;
- start = p + 1;
+ start = p + esc + 1;
}
}
}
@@ -1337,7 +1338,8 @@ expmeta(char *enddir, char *name)
atend = 1;
} else {
atend = 0;
- *endname++ = '\0';
+ *endname = '\0';
+ endname += esc + 1;
}
matchdot = 0;
p = start;
@@ -1363,7 +1365,7 @@ expmeta(char *enddir, char *name)
}
closedir(dirp);
if (! atend)
- endname[-1] = '/';
+ endname[-esc - 1] = esc ? '\\' : '/';
}
#endif /* HAVE_GLOB */
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Inconsistent parameter expansion
> > I can't figure out why '*/FILE' and '*"/FILE"' are not expanded the same > > way... This and one from "[EXPAND] Fix slash treatment in expmeta" work with Etch: [EMAIL PROTECTED] dash -c 'echo "/"root*' /root [EMAIL PROTECTED] dash -c 'echo *"/FILE"' A/FILE B/FILE C/FILE D/FILE [EMAIL PROTECTED] > This is a bug in dash. The following patch should fix the problem, > provided that Ubuntu hasn't built dash with glob(3) enabled because > glob(3) has a similar bug and that needs to be fixed in glibc. What was/is whole story? What are FNMATCH_BROKEN GLOB_BROKEN? Thanks. -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Inconsistent parameter expansion
Oleg Verych <[EMAIL PROTECTED]> wrote:
>
>> This is a bug in dash. The following patch should fix the problem,
>> provided that Ubuntu hasn't built dash with glob(3) enabled because
>> glob(3) has a similar bug and that needs to be fixed in glibc.
>
> What was/is whole story? What are FNMATCH_BROKEN GLOB_BROKEN?
I added fnmatch(3) and glob(3) support to dash in order to tap
into existing libc functions rather than duplicating them. However
at the time it turned out that both were broken which is why these
macros were added until such a time when they were fixed.
The fnmatch(3) function is now correct as far as I know but
glob(3) still seems to be broken.
In any case you may enable them with --enable-fnmatch and --enable-glob
when running configure to see their effect on dash.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
shell and glibc (Re: Inconsistent parameter expansion)
> The fnmatch(3) function is now correct as far as I know but > glob(3) still seems to be broken. It seems, small glibc team cannot do much in areas without interest. Very surprising for me was recent discovery of big performance penalty of the most simple '^$' regexp; it turned to be glibc RE library problem: http://bugs.debian.org/475474 (bonus: 4 ways of doing one thing with `sed`, not with `perl`:) Thus, i think shell -- basic userspace tool, must be reliable with its implementation. There are many other ways of size reduction (more on that latter). -- To unsubscribe from this list: send the line "unsubscribe dash" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: shell and glibc (Re: Inconsistent parameter expansion)
Oleg Verych <[EMAIL PROTECTED]> wrote:
>
> It seems, small glibc team cannot do much in areas without interest.
Unfortunately all the cool kids want to work on the kernel instead :)
> Very surprising for me was recent discovery of big performance penalty of
> the most simple '^$' regexp; it turned to be glibc RE library problem:
>
> http://bugs.debian.org/475474
> (bonus: 4 ways of doing one thing with `sed`, not with `perl`:)
Have you seen http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65458 ?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe dash" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
