console/desktop integration

[Dave Cridland]

Dennis,

On Mon Aug  9 11:01:30 2004, Dennis Heuer wrote:
> my article focuses on how to integrate unknown but existing and 
> still used commandline tools.
> 
> 
Well, not really, to be fair.

Your article focuses on two distinct problems, and attempts to 
provide one potential solution for one of them, which I believe is 
the wrong solution to the problem specified, and moreover its 
proposed implementation is both naive and flawed.

I do, however, think that both problems are valid ones.


> So, what's the point about "not getting developers to support it". 
> As I wrote, not every tool on earth must support it. And, most apps 
> support "-h,--help" or "-v,--version" or "-u,--usage" in either way 
> today. That not really all (100%) tools support these parameters 
> doesn't mean anything. It's like not all archives support 
> configure/make. However, more than 80% do, and you always find an 
> alternative app using it.
> 
> 
So what's the alternative to 'nohup'?

$ nohup --list-params
nohup: appending output to `nohup.out'
nohup: cannot run command `--list-params': No such file or directory

That just tried to execute something. Not good. If someone snuck in a 
shell script somewhere on my path called '--list-params', I'd have 
just done something I didn't mean to. Now, obviously, someone 
sneaking that shell script onto my path would indicate a security 
problem, but I suspect it's made worse by this.

Moreover, yes, every tool (not just console) *must* at least fail 
gracefully when faced with this command line parameter.

Furthermore, please, please, try to remember that this is not just 
about free operating systems - there are commercial UNIX variants 
which deploy GNOME et al. So you'd have to convince them to add all 
that stuff to their utility set.

They don't have to do that for D-BUS, since D-BUS doesn't apply to 
most of these things, or else is there to provide functionality that 
these tools already handle, such as the HAL. Even if this were the 
case, adding functionality to a tool doesn't mean that adding more is 
acceptable.


> The second possible approach is creating a database like an 
> RDF-based system, as was mentioned at Footnotes.org. This would not 
> be maintained by the developers themselves, pushing the work to the 
> users or maintainers (distributors) who will never catch up if 
> there's not a simple way of producing the db automatically. This is 
> what my approach offers. My approach also offers the documentation 
> of the parameters, not only the app type.
> 
> 
With a seperate database, developers may support a machine readable 
parameter system - and packagers can fill in the gaps where they 
don't. It's division of labour, and thus it's more likely to happen. 
This has been proven hundreds of times before. Just consider 
packaging itself, for instance.

Moreover, for existing tools on proprietary operating systems, it's 
unlikely to ever get supported by the tool itself. I swear some of 
those proprietary UNIXes have stuck with the same 'find' and 'ls' 
source for the past decade or two.

Your suggested approach can potentially cause programs to be executed 
with don't support your proposal, causing unknown side effects.

Of course, having a command line switch that generates a database 
entry is useful, however, it would never be universal, and is an 
implementation detail belonging in a recommendations document, rather 
than a standard.


> How can he make them work fine with, say, nautilus console (an 
> often formulated wish)? How the user can select these tools from 
> dialogs in an almost HIG-compliant way?
> 
> 
Well, many command line tools are just that - command line tools. 
Only a very few make sense to launch in a GUI.

I don't think your proposal, or a similarly designed working one, 
would be useful in all cases:

1) The GNOME Volume Manager (HAL interface).

I suspect a system event notification system would work much better 
here, and much more flexibly. The events to operate on could be 
centrally controlled. A limited number of applications would operate 
on a particular event, anyway. I don't ever want to run 'vi' or 'gcc' 
because someone inserted an audio CD, for instance.

I also only want to run my music player app in CD player mode - not 
in Ogg-player or movie-player mode, so not all command line switches 
are relevant here.

I think an event based system, running through a database of possible 
command lines, would be considerably more usable for this.

2) The GNOME "Run Command..." dialog.

Actually, this runs a string through the shell, doesn't it? So to 
properly handle things, it'd need to be able to construct shell 
pipelines, etc. This is programming, basically. I understand that a 
number of researchers have examined a GUI method for generic 
programming, and assigned it to the 'failed idea' bucket, going back 
to text editors.

Even if you restrict the concept to running a single command, I'd 
appreciate a GUI rendition of 'find', and the proposed output of 
'find --list-params' to go with it. I cannot actually think of a 
suitable way of achieving what you want here.

Where I can see your proposal - admittedly modified so as to seperate 
the database of parameters from the command binary itself - coming in 
very useful is in a programmer's editor for handling shell scripts, 
where an automated help system would be able to use this to great 
effect, probably saving a substantial amount of time.


> There was another person saying that "generating" the parameter 
> text is complex. No, it isn't. It is the same complex as printing 
> the help message (application --help).
> 
> 
It is significantly higher complexity, to be fair.

I think you're confusing the ability to write out the text with the 
difficulty and complexity of creating and maintaining the text in the 
correct format, and matching with the real parameters of the 
application.

This is equal complexity, of course, to having it in a seperate file 
somewhere, however, the difference is that in a seperate file, it's 
easy for someone else to maintain it outside the development proper, 
should that be required.

Finally...

This is a mailing list about standards and specifications. I think 
everyone here is very detirmined to get everything 'right', and that 
includes you as well, and that's good. As a result, everyone does 
tend to feel a little strongly, and discussion can get heated. This 
just happens, and I wouldn't worry about it. The purpose of standards 
discussion largely boils down to one person putting up a suggestion, 
and everyone else picking holes in it, so that hopefully, what 
emerges is 'right' in at least most people's minds, and has no 
obvious holes.

When someone attacks your idea harshly, that's not an attack on you 
at all - I think I'm safe speaking for everyone in that we all 
appreciate the effort you've gone to, and it's sparked a few debates 
from which, hopefully, several valuable things will emerge. Your 
original idea will almost certainly not be one of them, but then, 
it's very rare that one person's idea is taken up wholly, anyway.

So please don't attack people simply because they disagree with you. 
Not only will people think less of you, but they'll probably becomes 
biased to your idea as well - this does happen, sadly, just look at 
the RFCs discussing SYN Cookie techniques, and compare with DJB's 
style of argument. (Hint: There are no RFCs discussing SYN Cookie 
techniques, because DJB launches bitter attacks against anyone who 
offers an alternative point of view, and people got too annoyed with 
his style to see that his arguments are sometimes valid.)

Dave.