Since I just came across one of these again, here is an example,
again BLFS and not LFS... this time in ghostscript:
chown -v -R root:root /usr/local/share/ghostscript/fonts
J.O.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See th
Matthew Burgess wrote:
Err, *hundreds* of lines? What commands did you add '-v' on to make it
output that much. In the vast majority of cases it should just be one
line per command, I would imagine.
Ahemm... May have been an exaggeration, but nevertheless, there was
a lot of "scrolling away
On 7/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote these words on 07/28/05 12:16 CST:
>
> > Err, *hundreds* of lines? What commands did you add '-v' on to make it
> > output that much. In the vast majority of cases it should just be one
> > line per command, I would im
Matthew Burgess wrote these words on 07/28/05 12:16 CST:
> Err, *hundreds* of lines? What commands did you add '-v' on to make it
> output that much. In the vast majority of cases it should just be one
> line per command, I would imagine.
I took the OP to mean the BLFS additions of -v. Over o
Jens Olav Nygaard wrote:
Since everybody seems to be so positive... I found it extremely
annoying when I realized this change, as hundreds of lines
scrolled by, and all the useful information from previous
commands just scrolled into oblivion.
Err, *hundreds* of lines? What commands did you a
Matthew Burgess wrote:
policy. Does anyone have any strong opinions either way?
Since everybody seems to be so positive... I found it extremely
annoying when I realized this change, as hundreds of lines
scrolled by, and all the useful information from previous
commands just scrolled into obli
Gerard Beekmans wrote:
Matthew Burgess wrote:
the result of running the command was (especially in the case of 'ln')
Do you mean to say that the book would then also show all the to-be
expected output?
No. The expected output should be obvious, therefore it should also be
obvious to the
Greg Schafer wrote:
Oops. Please forget I even mentioned the "old host" issue. It's pretty
much a non-issue seeing as LFS demands a 2.6 kernel on the host these
days. This means `mkdir' vs `install -d' doesn't really belong in this
thread. Sorry for the diversion..
Right. Well tonight's turning
Jeremy Huntwork wrote:
> I understand what the proposal was about. You mentioned the possibility
> of some of the host tools not being able to produce verbosity as
> expected, with the specific example of mkdir. That led me to wonder how
> often we currently use mkdir and so I branched...
Oops
Randy McMurchy wrote:
The biggest reason to use install -d instead of mkdir is that using
the install -d command allows you to also place a -m755 (or whatever
mode you wish) on the command. This creates directories with the
desired permissions, unlike mkdir which creates the directory using
permi
Greg Schafer wrote:
Jeremy Huntwork wrote:
I recall that early in chapter 6 there was a change to 'install -d' over
'mkdir' for the Create Directories section
Yes, but the proposal is not about that.
I understand what the proposal was about. You mentioned the possibility
of some of the h
Greg Schafer wrote these words on 07/27/05 19:25 CST:
> IMHO it's not worth it for those obvious ones. As Randy says, only when
> custom perms are needed should you need to resort to `install -d'
Just to set the record straight. I am not saying to use 'install -d'
when "custom" perms are required
Jeremy Huntwork wrote:
> I recall that early in chapter 6 there was a change to 'install -d' over
> 'mkdir' for the Create Directories section
Yes, but the proposal is not about that.
> Plus, any time we create a separate build directory, as in:
> mkdir ../binutils-build
IMHO it's not worth it
Jeremy Huntwork wrote these words on 07/27/05 19:01 CST:
> I recall that early in chapter 6 there was a change to 'install -d' over
> 'mkdir' for the Create Directories section though I can't remember the
> reason behind that particular change. I don't suppose it would hurt to
> change out the
On Wednesday 27 July 2005 17:01, Jeremy Huntwork wrote:
[...]
> Plus, any time we create a separate build directory, as in:
> mkdir ../binutils-build
I see the logic in using install in the other directories as you
suggest, not necessarily in the ../*build ones.
My $.02
SeattleGaucho
--
http:/
Greg Schafer wrote:
Just be careful when using them early in the build before you've installed
coreutils. You need to be wary of host issues. For example, `mkdir' on
RH62 doesn't support -v (but `install -d' does :-)
I recall that early in chapter 6 there was a change to 'install -d' over
'mk
Matthew Burgess wrote:
> Some time ago, BLFS added the '-v' (verbose) flag to common Unix
> commands ('mv', 'ln', etc.) so that it was clearer to readers
Don't take this the wrong way, but I've been doing exactly that for quite
a while so I fully support LFS adopting it.
> a) what
> the result
Matthew Burgess wrote:
the result of running the command was (especially in the case of 'ln')
Do you mean to say that the book would then also show all the to-be
expected output?
and b) if they'd made an error. It also, of course, helps greatly when
perusing log files. I'm therefore propo
Matthew Burgess wrote these words on 07/27/05 15:23 CST:
> Some time ago, BLFS added the '-v' (verbose) flag to common Unix
> commands ('mv', 'ln', etc.) so that it was clearer to readers a) what
> the result of running the command was (especially in the case of 'ln')
> and b) if they'd made an
19 matches
Mail list logo
