Inconsistencies in DEBUG() code

Boyce, David David.Boyce at
Tue Mar 23 21:42:35 GMT 1999

[ Apologies for using Outlook - I have no choice. Attempting pure text mode
... ]

Using Samba 2.0.3, I believe I've uncovered a number of inconsistencies with
debugging msgs on the client side:

-> "man smbclient" says that the default debug (-d) level is 0. However, in
the code it's initialized to 2.

-> The initial "Added interface ip=x.x.x.x bcast=x.x.x.x nmask=x.x.x.x"
message cannot be suppressed no matter what the debug level is set to. This
is because the load_interfaces() function is called very early in main() -
before getopt processing. There's no obvious reason why it needs to happen
so soon, but if so perhaps some argument pre-processing could be done for
the -d and -E flags? Or the debug msg could be synthesized later on.

-> For the same reason, -E has no effect on where the "Added interface"
message goes.

-> The "tar: dumped xxx tar files" and "Total bytes written: xxx" messages
in -T mode are level 0, which means that in theory they can't be turned off.
I can't think of any good reason these should be non-negotiable.

-> Fortunately, however, though the documentation makes no mention of it,
DEBUGLEVEL is implemented as a signed int. Thus it's possible to use "-d -1"
to turn off even level-0 debugging statements. I see this as a feature, by
the way.

By the way, what I'm really trying to do is get a boolean status on the
presence of a certain file within a script. I.e. I need to poll various
shares to see if this file is present. But there seems to be no way to get a
nonzero exit status from smbclient if the connection itself is successful
(it seems to behave like rsh in this way) so I'm trying to do something like
(in Perl):

	my $data = `smbclient //$server/$share -Tqc - $dir/$file`;
	die "unable to connect to //$server/$share" if $?;
	if ($data) {
		print "Yes - $dir/$file is present\n";
	} else {
		print "No - $dir/$file is missing\n";

but I'm plagued by the unwanted debug data. It would be nice if smbclient
would, like a shell, return the exit code of the last command such that:

	smbclient //$server/$share -D $dir -c "get $file"

would return zero or non-zero depending on the presence of $file. Even more
so, shouldn't smbsh behave like other shells (it doesn't) in this regard? In
fact smbsh doesn't implement a -c flag. Come to think of it, since smbsh is
still under development and not AFAIK officially released yet, wouldn't it
be possible to rework its CLI interface to be orthogonal to those of any
known shell, and then just pass unrecognized flags to the underlying $SHELL?
This would buy a lot for cheap IMHO.

Late-breaking news - apparently smbclient doesn't print any debug data if
not connected to a tty, so `smbclient ...` actually does the right thing.
The other issues remain, however.

David Boyce

More information about the samba-technical mailing list