What happened to zillion switches in dancing-cartoon version?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
After finally spending a few minutes testing the 2009 ver. KDE
I'm trying to make a DVD backup of my most important data.

I seem to remember that when I looked at a `man` ten years ago
it showed the man-ID and that I was on line 843 of 1352 total
lines. So that when I skipped between man A  & man B, I could
see which one I was looking at, and if it was  the one with the
stuff at approximately 40% in the man.

That seems a real useful facility compared to the dancing-cartoonS
of newer-kde.
Eg. when you're reading `man cdrecord` and it's got paragraphs
about 'mkisofs`, you don't need to wonder if you're reading the
'man mkisofs', which you opened somewhere else.

Why does `cdrecord --help | wc -l`
show "0", so now I've got no evidence of how many switches
this absurd utility lists?
And, related: `cdrecord --help | less` scrolls to the end, so
that you can't see the most-important: up-front <syntax>.

How does the dancing-cartoon version manage to work like
a toaster without a zillion switches?

I finally found where 1GB of `df` went to, by `mkisofs`
but is there any way to ask  to `find <files BIGGER THAN nKB>` ?
Previously [according to my log-notes] the minimal:
`mkisofs -R <dir-tree> | cdrecord <device args>`
saved files with DOS:8.3 names -- which is crap!!

Now I've spent hours generating a log of failures,
where the latest one is for:-
mkisofs -R /mnt/p11  | cdrecord -v fs=6m speed=2 dev=0,0 -
   which reports:-
Quoted text here. Click to load it

It seems that the 'fifo is not getting written to'?
I can't mount blank-DVDs and assumed that 'cdrecord` works
like `dd`.
Another 'configuration' reported that <the buffer received a
premature EOF>

Does anybody know how to save a dir-tree to DVD with these
2 old utilities, instead of with a dancing cartoons utility?

== TIA.

Re: What happened to zillion switches in dancing-cartoon version?

Sat, 07 Apr 2012 10:41:36 +0000, no.top.post did cat :

Quoted text here. Click to load it

the reason is simple, will you have a guess?
$ cdrecord --help 2>&1 | wc -l

Quoted text here. Click to load it

why absurd? if you don't need to use it give it a break,
don't try and think hard about stuff you misread the very first

Quoted text here. Click to load it

same punition for stubborn bad-readers ;-)
$ cdrecord --help 2>&1 | less

Quoted text here. Click to load it

probably using the switches behind the smokescreen.
Quoted text here. Click to load it

yes, there are several ways to do so, I'd favor 'find'

Quoted text here. Click to load it

so many reasons you'd have this in your log-notes, main
might be your "cdrecord" was not the real one (was it
a Debian those years some third dev asst west coast went amok
about rewriting his own bugs nest to demonstrate he wasn't
able to read docs and code?
another favorite reason might be you took wrong notes or
misread  the results in a flabbered test attempt?

after all you are the on who's yourself and you should
now try and get used to it so why always coming back in
groups before you tried and give your self a chance?

Quoted text here. Click to load it

see, you just spent hours to generate failures then log them
that hardly seems the right way to go if you're interested in
going somewhere in the end...

Quoted text here. Click to load it

could be, try something along this example:
$ cd /...thepathwhereyourgoodiestreeis/
$ mkisofs -o /tmp/yourdvd.iso \
  -R -J -A "most important data bkup" \
  -hide-rr-moved \
  -v -d -N \
  -m 'somestuffyoudontwant*' \
  -V "VolumeID" .
and use cdrecord or growisofs at your convenience to
burn the cake when you're sure your ISO holds the vault you need.

Re: What happened to zillion switches in dancing-cartoon version?

no.top.post@gmail.com wrote:
Quoted text here. Click to load it

Why you asked this in alt.comp.hardware, I'll never know.

This is a question about commands with a zillion options.
Such a design implies the person writing the software (mkisofs, cdrecord)
wants *you* to waste hours of your time, figuring it out. It's
meant to be annoying. It's highly unlikely a person with
a polished, command line invocation, is reading this thread.

Use the cartoon version, if you don't have hours to spend, and
a pile of CDs to waste. Brasero sucks. Don't use it. I use K3B,
and like it enough, I remastered a Ubuntu LiveCD, tossing OpenOffice,
just so I could have a copy of K3B in a Gnome environment. The feedback
you get from K3B, while attempting to burn an ISO, is very useful if
you've forgotten a step (like, forgot to erase your rewritable media).
(K3B is a KDE utility, which means sucking in half of KDE just so you
can have it.)



(There are lots of tutorials around. This one doesn't answer the question
 so I move on.)


(OK, now we're getting some where.)



   "If the overall speed of the system  is  sufficient  and  the
    structure  of  the  filesystem  is not too complex, cdrecord
    will run without creating an image of the ISO-9660  filesystem.
    Simply run the pipeline:

    mkisofs -R /master/tree | cdrecord -v -dao fs=6m speed=2 dev=2,0 -

So that's an example of a recipe. The "dao" or disk-at-once might make
a difference. Given the large number of arguments these programs take,
I expect a good number of wasted discs until the recipe is right.

ISO9660 stores files in 8.3 mode. But there are options.


   "The standard has three different levels for interchange

    Level 1: File names are limited to 8.3, uppercase, 8 directory levels
    Level 2: Up to 180 characters. Single byte holds stringlength.
    Level 3: Packet writing"

Back to the mkisofs manual page.


    -iso-level level

So there's a level option, which will do a better job on file names.


Note that some software idiots, have spoiled the "pipe" concept in
Linux, by insisting that some commands use up all of system RAM
as a container for the intermediate results. The end result for me,
is now I can no longer trust the "pipe" semantic when I sit down
to use the command line. Good work, boys... (GNU, I'm talking to you...)

What you'll notice is, if you work with large objects (in this case,
that 4GB plus ISO9660 destined for the DVD), *some* Linux tools will
end up trying to use all system RAM to hold the intermediate pipe
contents, instead of using FIFO and blocking until the downstream
command catches up. This results in a "not enough RAM" error, rather
than your piped command sequence completing. Optimization, my ass.
It means some things I used to be able to do in Linux, I can no longer


Site Timeline