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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
