sh script problem with capturing return code

[Fbsd8]

Lowell Gilbert wrote:
> Fbsd8 <fbsd8 at a1poweruser.com> writes:
> 
>> Lowell Gilbert wrote:
>>> Lowell Gilbert <freebsd-questions-local at be-well.ilk.org> writes:
>>>
>>>> I think it's a real bug, and the test cases don't cover "extra" elements
>>>> at all. Now I just have to figure out the right fix.
>>> I'm pretty sure that the fix is just to set rval on jumping to the
>>> "extra" tag in vwalk() in src/usr.sbin/mtree/verify.c.
>>>
>>> But my hot water heater just exploded, so I may not look at code for a
>>> few more days.
>> Hello Lowell,
>> Thank you very much.
>> I was going crazy trying different combinations of options and script
>> logic. I want to thank you for taking my problem seriously and taking
>> the time to do your own test cases to verify my findings. Now that I
>> know it's a genuine bug in mtree, I can make my plans accordingly. Any
>> fix to the mtree utility will take some time to filter down to a
>> regular RELEASE. Maybe 9.2 or the big jump to 10.0 by the end of
>> 2013. I will leave it up to you the file a PR on this and follow
>> through.
>> Thanks again, people like you are what makes this questions list so
>> valuable and FreeBSD such a great OS. You did outstanding work.
> 
> Actually, in retrospect I think it was pretty trivial. I think the
> following patch is the right fix for the problem, although I am not
> completely certain.
> 
> ================================================================
> Index: /usr/src/usr.sbin/mtree/verify.c
> ===================================================================
> --- /usr/src/usr.sbin/mtree/verify.c    (revision 245177)
> +++ /usr/src/usr.sbin/mtree/verify.c    (working copy)
> @@ -149,6 +149,7 @@
>                 }
>                 (void)fts_set(t, p, FTS_SKIP);
>         }
> +       rval = MISMATCHEXIT;
>         (void)fts_close(t);
>         if (sflag)
>                 warnx("%s checksum: %lu", fullpath, (unsigned long)crc_total);
> ================================================================
> 
> This fixes the problem that was bothering you, but the interactions of
> different features are complicated, and many of them are documented in
> fairly loose language.
 >
Is that the diplomatic way of saying the manpage for mtree sucks, and 
leaves a great deal to be desired?

> 
> Would you be interested in extending the test suite for this program?
> There are some tests in /usr/src/usr.sbin/mtree/test/, but they don't
> cover your issue. I'm particularly concerned with interactions between
> mtree(8) options like -u, -U, -q, -d, and specification keywords like
> "optional", "nochange", and "ignore". I would feel more comfortable if
> someone else wrote up new test cases (because programmers generally
> don't -- can't -- test their own blind spots), although I'll certainly
> do it if no one else does.
> 
> I haven't submitted a PR yet, but I'll do so as soon as I've translated
> my test case into a form that can be used in the PR.
> 
> 
> 

Lowell here is my situation, I support a port and needed a method to 
interrogate the content of a small directory tree for correctness before
processing it's content. I first developed a coding logic using mtree 
for this purpose, but that brought to light this mtree bug which is the 
subject of this post.

Since my port only uses utilities that are contained in the base system 
of a RELEASE I could not very well wait for any patches to mtree to 
filter down into a RELEASE before updating my port. So instead I
developed a coding logic using diff that does the same thing I was doing 
with mtree but diff issues the correct return codes. I have since 
updated my port in the ports system.

When it comes to testing your patch sure I would like to. But here again 
I have a problem. For security reasons I can not use source code to 
install or update any operating system. I have no sources on my system 
to compile from. I use the fresh install method from a downloaded 
disc1.iso burned to cdrom.

This way I know beyond a shadow of a doubt I have an un-compromised, 
clean, virgin system to start with and nothing present or left over from 
previous running systems that can be used to compromise the system.

Now if you would use gzip to compress the binary patched version of 
mtree you have been testing with and email it directly to me offline of 
this list, then sure I will test it inside a jail and even play around 
with the other option flags your interested in and provide you feed back 
off list.

Joe