Re: [lfs-support] Building Check-0.9.10 fails and fixed
That is true. I have been using this setup for so many versions and it worked so I never noticed. Thanks for the pointer. I have added the diff for to fix the problem, in case anyone comes across the problem. --- lib/libcompat.h.orig2013-10-17 19:26:21.341263508 + +++ lib/libcompat.h2013-10-17 19:28:58.780713970 + @@ -130,7 +130,7 @@ * As the functions which use timer_t are not defined on the system, * the timer_t type probably also is not defined. */ -typedef int timer_t; +/* typedef int timer_t; */ int clock_gettime(int clk_id, struct timespec *ts); int timer_create(int clockid, struct sigevent *sevp, timer_t *timerid); - Nii Nai On Thu, 17 Oct 2013 22:11:12 +0200, Denis Mugnierwrote: The LFS book said that /bin/sh should be a symbolic or hard link to bash not to dash -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] No Pattern Matching Using $foo in Chroot Environment
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
Re: [lfs-support] No Pattern Matching Using $foo in Chroot Environment
Dan McGhee wrote:
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)
Does $foo exist in the chroot environment?
On my system it's man-pages-3.54 so
# foo=man-pages-3.54
# ls /sources/$foo*
/sources/man-pages-3.54.tar.xz
works fine. Note that if you did specify '$foo=man-pages-3.5.3' then 1)
the syntax is wrong, and 2) the man pages file name is formatted with an
extra dot which will result in 'No such file or directory'.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] No Pattern Matching Using $foo in Chroot Environment[SOLVED]
On 10/18/2013 01:38 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
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)
Does $foo exist in the chroot environment?
On my system it's man-pages-3.54 so
# foo=man-pages-3.54
# ls /sources/$foo*
/sources/man-pages-3.54.tar.xz
works fine. Note that if you did specify '$foo=man-pages-3.5.3' then 1)
the syntax is wrong, and 2) the man pages file name is formatted with an
extra dot which will result in 'No such file or directory'.
-- Bruce
Yup, forests and trees again. Frustrating. The good news is that I
learned a lot more about bash this AM. Including the preferred way to
redirect standard output to standard input. word. Easier to remember
than 21.
Everything works fine now.
Thanks, Bruce
red-faced Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] Grateful
I decided to write this since even in my old age I like receiving
feedback that my efforts are not in vain.
Hats off to you {,B}LFS editors, maintainers, developers and list
supporters. The job you do is almost insurmountable, yet you do it with
aplomb. The LFS book is exactly what it says it is: a follow the
directions exactly learning experience to build an operation system.
That takes work and attention to details. Not only that, but you take
care of broken links on the web site, e-mails not automatically going to
those who need them--yes, I follow the list--and all sorts of other
housekeeping chores.
But given all of this, you take the time to aid people. I know I can be
a pest because I like to have things right in my mind before I go
ahead. It's worse right now since I'm scouring the rust from my
building skills. Just this week, Ken Moffat, Bruce Dubbs and Pierre
Labastie have taken the time to point me in the right direction so I can
do things the way I want to.
I remember from my working days that the trenches can get so deep I
wanted to throw in the towel. I urge you not to lose your attitudes.
Thanks to you all.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Solid Red Block Cursor in TTY (Terminfo)
Esben Stien b...@esben-stien.name writes: I'm trying to make my cursor a solid red block.. Nobody has any idea or any pointers? -- Esben Stien is b0ef@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Grateful
Yes they are the best..!
On Sat, Oct 19, 2013 at 3:12 AM, Dan McGhee beesn...@grm.net wrote:
I decided to write this since even in my old age I like receiving
feedback that my efforts are not in vain.
Hats off to you {,B}LFS editors, maintainers, developers and list
supporters. The job you do is almost insurmountable, yet you do it with
aplomb. The LFS book is exactly what it says it is: a follow the
directions exactly learning experience to build an operation system.
That takes work and attention to details. Not only that, but you take
care of broken links on the web site, e-mails not automatically going to
those who need them--yes, I follow the list--and all sorts of other
housekeeping chores.
But given all of this, you take the time to aid people. I know I can be
a pest because I like to have things right in my mind before I go
ahead. It's worse right now since I'm scouring the rust from my
building skills. Just this week, Ken Moffat, Bruce Dubbs and Pierre
Labastie have taken the time to point me in the right direction so I can
do things the way I want to.
I remember from my working days that the trenches can get so deep I
wanted to throw in the towel. I urge you not to lose your attitudes.
Thanks to you all.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
