Hi,
> > You already get a warning when loading a non-ISO-image.
> There is one small shortcoming though: if the input image is not an iso
> but is filled with only nulls (or is empty), then xorriso does not fail
Yes. Such files count as blank medium.
I did not think of this case when making the proposal to you.
> I had expected that such a complex piece as xorriso would be able to do
> that itself (testing that the input is blank).
It does recognize this state. But it already has an own
harmless interpretation for it: blank medium suitable
for writing.
On such a medium it starts by an empty ISO image model.
This is a normal media state. No reason for a warning.
You get a warning, though, if you submit a non-blank non-ISO.
That's because these "media" have to be blanked before an
ISO session can be written to them.
You may probably recognize the blank-ISO situation by a
reply "0" from:
xorriso -indev not_existing_file -ls / -- \
2>/dev/null | wc -c
> > In xorriso's -find, -exec is not a test and can only appear once.
> > [...] It would be quite some effort to enable multiple -exec
> That is why I suggested a different name of -fexec that would be a test.
I missed this point.
> What I had in mind is the possibility to make arbitrary tests against
> the filename only (that would be passed on the command line of a system
> command) and possibly against other attributes like size, mode, time
> that would be passed as environement variables ISO_SIZE, ISO_MODE etc.
>
> $ xorriso -indev img.iso -find \
> -fexec sh -c 'test "$1" = "$2" || test $ISO_MODE = 755' s "$name" '{}'
\; \
> -exec lsdl
Reading man bash ...
I understand that "$1" and "$2" shall become the value of shell
variable "$name" (evaluated by the shell that starts xorriso) and
the path of the currently examined ISO file object (caused by '{}').
The parameter range of -fexec shall end at "\;".
"s" is a dummy sacrifice to the -c interpreter of sh, so that "$name"
does not become "$0".
I'm not happy with the semicolon. Probably a user-defined separator
word is preferrable. It would be the first parameter of -fexec and
its next occurence would mark the end of -fexec.
Like
-fexec + sh -c ... +
Similarly i'm not happy with '{}', because it would be a reserved
word among the parameters of fexec.
The solution could be user-defined word given as second parameter.
Like
-fexec + +path /bin/sh -c ... s "$name" +path ... +
The user could still make it behave quite shell-ish then:
-fexec ';' '{}' /bin/sh -c ... s "$name" '{}' ... ';'
I'm also not happy with the potential to perform arbitrary actions
on the computer system. One can easily shoot one's foot.
But i accepted this for -concat "pipe" and external filters already.
So this is not a hard obstacle. I just insist in not using $PATH
for finding the external program.
I'll put this proposal on my ponder-and-todo list.
> I think that it is important to have the possibility to disable patterns
> (or regexps), as the alternative is often to have to escape them, which
> is not portable I believe,
Especially xorriso does not support escaped wildcards.
Either -iso_rr_pattern interpretation is enabled or disabled
for a whole command.
There are two reasons for this reluctance to follow the shell
habits:
- xorriso tries to avoid interpretation collisions with the special
words and characters of a shell.
(E.g. i do not use ';' as separator by default, because then
one would have to protect it from interpretation by the shell.)
- I deem several traditional syntax and semantic gestures of
Bourne Shell descendants cumbersome. Among them is escaping
of special or unprintable characters, and the behavior of
commands like "cp" and "cd" with multiple file arguments.
Further, the shell is too eager to execute external programs,
which is something you would not necessarily expect from a
program that produces ISO 9660 filesystems.
I am aware that by this i deny certain features to my users,
which a shell would be able to offer.
(Given the architecture of libisoburn API, it would be well
possible to wrap xorriso's commands into a real shell-ish
interpreter, or a programming language like Tcl.)
> > This feature is now in the SVN of libisoburn.
> I haven't had a chance to test it yet.
That's quite convenient for both of us. :)
I just found a bug with the recognition of -or_use_pattern
and wonder how it could pass my tests two weeks ago.
http://libburnia-project.org/changeset/5327
> > xorriso -indev image.iso -return_with WARNING 32 -report_about WARNING \
> > -find / -use_pattern off \
> > -wholename "$name1" -or -wholename "$name2" -exec lsdl
> This does not even fail when none of the files are found.
-find is not supposed to warn if no file is found.
This situation would be rather be recognizable by no output on
stdout.
>From your initial mail of 16 Apr 2014 07:00:22 +0200, where you
report about your experiments:
> xorriso -indev image.iso -return_with WARNING 32 -report_about WARNING \
> -find / -wholename "$name1" -o -wholename "$name2" -exec lsdl
I assume you got the WARNING event from the -indev command,
not from -find. The commands -return_with and -report_about get
into effect already before -indev. So its warning triggered a
non-zero exit value.
If you set -report_about to DEBUG you will get reported the
commands before their messages:
xorriso : DEBUG : Command: -indev
xorriso : DEBUG : Parameter: img.iso
... several unwanted debug messages ...
xorriso : NOTE : Loading ISO image tree from LBA 0
...
libisoburn: WARNING : No ISO 9660 image at LBA 0. Creating blank image.
...
xorriso : DEBUG : Command: -return_with
...
xorriso : DEBUG : Command: -find
...
As you already noticed, -return_with does not cause early abort
of the xorriso run. So -find was executed on the empty ISO image
model without result line or warning.
(You could populate the image model, apply commands
-outdev img.iso -blank as_needed
to make the "medium" ready for writing, and then write the model
as ISO filesystem to the "medium". So this empty image model state
of a "closed medium" has its valid use cases.
Somewhere i have a transition diagram for media states that looks
like a buddhist mandala.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Archive: https://lists.debian.org/49036669968011043...@scdbackup.webframe.org
