[lfs-support] No Pattern Matching Using $foo in Chroot Environment

Dan McGhee beesnees at grm.net
Fri Oct 18 11:11:01 PDT 2013


On 10/18/2013 10:08 AM, Dan McGhee wrote:
> I'm trying to run a script to build a package--I use the package users
> hint--which has the following:
> package=$(whoami) #In this case I'm man-pages-3.5.3
> packagedir=/sources
> archive=$packagedir/$package.tar.*
>
> Later when I want to define a variable containing the name of the
> directory into which tar will extract the archive, I have
> <pkgsrcdir=$(tar -tf $archive | grep / | head -n 1 | cut -d '/' -f 1)>
>
> The script bails out at this point complaining that there's no file or
> directory by that name.  Running <sh -x script_name reveals "archive =
> """ (BTW sh reports that $packagedir and $package are properly defined.)
>
> I have discovered that when I use {ls /sources/$(whoami) or $<anything
> that gives "man-pages-3.5.3">.tar*} as a package user, the return is
> <"man-pages-3.5.3*": No such file or directory.>  /sources is world
> readable and writable.
>
> If, however, I issue <ls /sources/man-pages*> the return is
> man-pages-3.5.3.tar.xz
>
> The pattern matching is fine for root:
> foo=man-pages-3.5.3
> ls /sources/$foo.tar.*
>
> gives the right answer.
>
> I've never encountered this before.  My hunch is that it's some
> environment variable.  I know that pattern matching involves globbing
> and clobbering, but I don't know enough--and can't find the info--to
> even experiment.
>
> In the past, something like this usually leads to, "I can't see the
> forest because there are so many trees in the way."  I don't know if I'm
> really focusing on those trees or not.
>
> In the meantime, I'm going to go through the bash man page.  I will be
> grateful for any pointers or suggestions.
>
> Thanks,
> Dan
>
>
>
Hopefully, I can be a little more secific about this now after reading 
for while.

First, it appears that in the chroot environment and use of 
$foo{*,.tar.[b,g,x,z][b,g,x,z][b,g,x,z]} in a command does not expand 
the file name in the way I understand the use of "*" and []. Ex. <ls 
/sources/$foo*> returns the no such file error, and <ls /sources | grep 
$foo> returns nothing. ($foo=man-pages-3.5.3)

 From the "Bash Reference Manual" I get:

Pattern Matching: After word splitting, unless the -f option has been 
set (see The Set Builtin 
<http://www.gnu.org/software/bash/manual/bashref.html#The-Set-Builtin>), 
Bash scans each word for the characters '*', '?', and '['. If one of 
these characters appears, then the word is regarded as a pattern, and 
replaced with an alphabetically sorted list of file names matching the 
pattern. (This is what does not happen using $foo*.)

Set Builtin: -f

Disable filename expansion (globbing). (The behavior is as if the -f 
option was given, but I don't know how to determine if it was and, if 
so, to reverse it.)

Shopt Builtin: extglob

If set, the extended pattern matching features described above (see 
Pattern Matching) are enabled.

and: globstar

If set, the pattern '**' used in a filename expansion context will match 
all files and zero or more directories and subdirectories. If the 
pattern is followed by a '/', only directories and subdirectories match.

I then ran <shopt -s extglob,globstar> and <echo $BASHOPTS> gives:
"cmdhist:expand_aliases:extglob:extquote:force_fignore:globstar:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath"

I looks like I have everything I need to do filename expansion and 
pattern matching is there, but the results are the same.

I haven't seen anything on how I can check on the behavior of $.

Once again, I can use pattern matching and expansion as long as I don't 
use the value of a variable. <ls /sources | grep man-pages-3.5.3> works 
great as does <ls /sources/man-pages*>.

In my script I would like to call the archives and the patch files 
knowing only the name of the package; i.e. $<package name>.tar.* and 
$<packagename>*.patch. But until I can get this pattern matching thing 
resolved, I'll need to manually enter these parameters in the script. 
And that's not "elegant." :)

Thanks,
Dan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20131018/f59de91b/attachment.html>


More information about the lfs-support mailing list