Randy McMurchy wrote:
> I am *not* in the class of individuals you mention above. Those guys
> are experts. I, however, don't know shit about GCC internals. :-)
Me is no toolchain expert. Those folks who write the toolchain code are
the real experts. But I'll say my piece anyway :-)
I cannot com
Tushar Teredesai wrote:
> IMO, the effort to payoff ratio of maintaining that page is not that high.
Hmm. In that case we should go ahead... :)
However, I think you meant too high.
OK. Unless someone (non-editor) asks with a good rationale, lets drop
the change summary idea.
-- Bruce
On Tue, 16 Aug 2005, Archaic wrote:
> On Tue, Aug 16, 2005 at 09:47:06PM +0100, Ken Moffat wrote:
> >
> > This vulnerability should be low risk for most of us, but I think it's
> > the sort of thing that ought to be applied.
>
> Agreed.
>
Hmm, I think I should have checked the patches list befo
Bruce Dubbs wrote these words on 08/17/05 16:18 CST:
> Randy McMurchy quoted from the Bash man page:
>> "Command substitutions may be nested. To nest when using the
>> backquoted form, escape the inner backquotes with backslashes."
>
> Can you say *ugly*. :)
I know, I know
I debated e
Randy McMurchy wrote:
> Matthew Burgess wrote these words on 08/17/05 14:33 CST:
>
>
>> Unfortunately, one can't nest backticks,
>
>
> I'm not so sure about that. From the Bash man page:
>
> "Command substitutions may be nested. To nest when using the
> backquoted form, escape the inner
Jim Gifford wrote:
> Tushar Teredesai wrote:
>
>> Now can someone please start a thread on LFS-dev to remove the
>> "Upgraded", "Added" and "Removed" sections from the LFS changelog so
>> that I can vote +1 on it.
>>
>>
>>
> The reason that is in LFS is because of the upgrades from the previous
Matthew Burgess, Aug 17, 21:50 +0100:
Obviously it'd be much easier to convince me if you both provided
reasons *why* you don't like the current format.
Confuses people :-)
http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2002-September/028191.html
Note that at that time,
On 8/17/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Richard A Downing wrote:
>
> > I prefer a straight forward chronological list of changes without all
> > the sections: Upgraded", "Added" and "Removed".
>
> Proposals generally are better received when they contain rationale (and
> no, "I p
Matthew Burgess wrote:
> Richard A Downing wrote:
>
>> I prefer a straight forward chronological list of changes without all
>> the sections: Upgraded", "Added" and "Removed".
>
>
> Proposals generally are better received when they contain rationale (and
> no, "I prefer" doesn't count!) :)
It s
I would not object to moving the upgraded, added, and new stuff to a
What's new type of page, I'm just against removing it from the book,
because it's a good source to view what the differences are between the
current release and branches.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS Use
Tushar Teredesai wrote:
> On 8/17/05, Richard A Downing <[EMAIL PROTECTED]> wrote:
>
>>I suggest LFS changes to this simplified form, although, as a
>>non-editor, I don't really have a vote! :-)
> Additionally, if folks do find these fields useful, I propose moving
> them below the changelog ent
Richard A Downing wrote:
I prefer a straight forward chronological list of changes without all
the sections: Upgraded", "Added" and "Removed".
Proposals generally are better received when they contain rationale (and
no, "I prefer" doesn't count!) :)
Seriously though, I think it provides a n
On 8/17/05, Richard A Downing <[EMAIL PROTECTED]> wrote:
> Over on BLFS-dev we have been changing our changelog format. In the cut
> and thrust of debate ;-) we discovered that at least two of us didn't
> like the LFS changelog format much.
>
> I prefer a straight forward chronological list of ch
Over on BLFS-dev we have been changing our changelog format. In the cut
and thrust of debate ;-) we discovered that at least two of us didn't
like the LFS changelog format much.
I prefer a straight forward chronological list of changes without all
the sections: Upgraded", "Added" and "Removed".
Tushar Teredesai wrote:
Now can someone please start a thread on LFS-dev to remove the
"Upgraded", "Added" and "Removed" sections from the LFS changelog so
that I can vote +1 on it.
The reason that is in LFS is because of the upgrades from the previous
version, we get a lot of questions on
Randy McMurchy wrote:
Matthew Burgess wrote these words on 08/17/05 14:33 CST:
Unfortunately, one can't nest backticks,
I'm not so sure about that. From the Bash man page:
"Command substitutions may be nested. To nest when using the
backquoted form, escape the inner backquotes with ba
El Miércoles, 17 de Agosto de 2005 21:16, Richard A Downing escribió:
> Does this mean a big change in the markup that we have to edit - does it
> introduce any more error prone-ness?
As you can see in the new XML, there is a template on the top ready to be
cut-and-pasted and then edited to inse
Matthew Burgess wrote these words on 08/17/05 14:33 CST:
> Unfortunately, one can't nest backticks,
I'm not so sure about that. From the Bash man page:
"Command substitutions may be nested. To nest when using the
backquoted form, escape the inner backquotes with backslashes."
--
Randy
On 8/17/05, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> Basically it's because, purely through habit, I only ever use backticks.
> Unfortunately, one can't nest backticks, so I came up with the mixture
> of backticks and $(). Oh, plus the fact that in my makefile based
> scripts the '$' needs e
Mike Hernandez wrote:
This stuff is all over my head but I'm just wondering why you would
mix backticks and $(). Why not just use: echo $(dirname $(gcc
-print-file-name=libgcc.a))/specs ?
Basically it's because, purely through habit, I only ever use backticks.
Unfortunately, one can't nest b
Bruce Dubbs wrote:
> DJ,
> I'm having trouble understanding the script in alsa-utils:
>
> #!/bin/sh -e
> DEV_BASENAME="${DEVNAME##*/}"
> N="${DEV_BASENAME#controlC}"
> case "$DEV_BASENAME" in
>controlC[0-7])
> x=0
> while [ $x -lt 20 ]
> do
> sleep 1
> if [ -
Hey folks... :) I was just checking the man page for "limits", and saw
this:
---
The limits file (/etc/limits by default or LIMITS_FILE defined config.h)
describes the resource limits you wish to impose. It should be owned by root
and readable by root account only.
---
However, currently, /et
22 matches
Mail list logo
