Finding an application

Is it possible to find out whether an application (in this case ps2pdf) is available on the path? I know about IfThere, but I’m not bothered about the actual location so long as it is accessible.

I won’t suggest trying *help ps2pdf because I know that that particular command does not offer help. However typing *ps2pdf will either produce a ‘file not found’ or a more arcane error message about its input file. That way you can work out whether it is there.

If you were interested in a programmatical solution, I think OS_File 15 is your best choice. E.g.:

SYS "XOS_File",15,"ps2pdf",,,"Run$Path" TO type%;flags%
IF (flags% AND 1)=0 AND type%=1 THEN PRINT "Yes" ELSE PRINT "No"

There’s also OS_FSControl 37 if you find yourself interested in the location of a file rather than just its existence.

Not sure this works

>LIST
   10 REM >d
   20 SYS "XOS_File",15,"ps2pdf",,,"Run$Path" TO type%;flags
   30 IF (flags AND 1)=0 AND (type%=1) THEN PRINT "Yes" ELSE PRINT "No"
>RUN
No
REM type%=0 flags=6
>*ps2pdf
: Unable to open the initial device, quitting.

Fair enough! I don’t think I’ve used OS_File 15 before so I’m probably doing something silly.

The little snag in this case is that ps2pdf is not on Run$Path, it is a GhostScript alias.

*show *ps2pdf
alias$ps2pdf : /SDFS::RISCOSpi.$.!BOOT.Resources.!Ghostscr.bin.ps2pdf %*0
*

To verify ps2pdf is present try :-

*ps2pdf --help

Ah. I’m wanting to do it programatically. I’ve ported the UNIX-based text formatting program, lout, to run on RISC OS. It works fine from the command line (although it expects UNIX-style filenames) but I’m writing a front-end for it using Dr Wimp which puts an icon on the icon bar and, when a text file is dragged to it, generates (using lout) a Postscript file.

I then call ps2pdf to convert the ps file to a PDF–again, this works, but I’d like to be able to tell whether ps2pdf exists and, if it doesn’t, to do something graceful like display an error box. The Dr Wimp program calls an obey file which calls lout and ps2pdf as and when needed.

(BTW lout is a text-formatting program similar in some respects to LaTeX, but lighter-weight and produces Postscript files directly. Obviously it doesn’t do everything LaTeX does but it’s still pretty capable and can do equations, tables, diagrams etc. If you want to search for details it’s probably better to searc under it’s full name of “Basser Lout”. It’s of Australian origin-perhaps the word lout doesn’t have the same connotations there as in the UK.)

To verify ps2pdf is present try :-

*ps2pdf —help

Ah! That explains it – I had tried *help ps2pdf
*ps2pdf /?
*ps2pdf -help
*ps2pdf -h
and given up…

Ah! That explains it – I had tried

Fairly typical of Unix / linux originated utilities – the help is one of the above except when it isn’t, like when it is something of the form ps2pdf ? ( no / )

How does the RISC OS *Help command work anyway? If anyone made a BASIC or C utility it would only respond to arguments in the same way as the linux binaries, depending on what arguments it recognises. BTW the most commonly used in Linux is either -h or —help or both, sometimes using -h for the abreviated version. Sash is a shell, and it has implemented ‘help’ as a command for it’s packaged commands in a similar useage to RISC OS *help. But what is the mechanism for adding a help item to the RISC OS *help?

How does the RISC OS *Help command work anyway?

Modules provide help on themselves and the commands that they offer.
For most cases, you simply say “here’s my command, here’s its flags, here’s some help to print if anybody asks” and let the OS take care of the rest.

Programs (defined as “anything that is not a module”) do not interface with the *Help mechanism.

BTW the most commonly used in Linux is either -h or —help

And the most commonly used in Windows is /?…
The habit of Linux/Unix programs to require a double-dash for parameters longer than a single character is somewhat annoying, I find, as I’m used to RISC OS’s behaviour where only a single dash is required; re. *ChangeDynamicArea for a good example. Also *Type and *WimpSlot. Perhaps because OS_ReadArgs can be used to parse the parameters easily…I’m not sure what OS_ReadArgs would do if presented with a double-dash.

But what is the mechanism for adding a help item to the RISC OS *help?

Two conditions:

1. Must be a module.
2. Must provide a command.

If those conditions are met, you pretty much don’t have a choice, it’s part of how commands are defined.

So, it is to be used exclusively for modules then? Why does *help commands work when there is no module with that name? I dont have any problem with it being just a modules utility, but we should adopt that policy instead of complaining about a program’s help arguments. I dont like the thought of lot of alias’s or unlinked help instructions that might result if a utility is removed, nor another use for package manager. At least a program’ arguments can be changed to your own preference if required. I think the double — will be around for a long time, it is used throughout gcc, autoconfig etc quite heavily.
Edit: quite often entering a binary name without an argument will return either useage info or the help text, one example I can think of is *Fat32Format. Possibly this is the most user friendly way of assigning help to a command, though there may be BASIC utilities that would go off and do something other than providing info if you simply entered their name.

Why does *help commands work when there is no module with that name?

Simple. Because it matches the command name not the module name.
As Rick said, it is part of how commands (in modules) are defined.

Ah yes, and ‘*help help’ is of importance here.

I dont have any problem with it being just a modules utility, but we should adopt that policy instead of complaining about a program’s help arguments.

…the problem with this is that modules and user programs are not the same thing.
In the case of modules, actually, we’ve been rocking that policy since 1987.

I dont like the thought of lot of alias’s or unlinked help instructions that might result if a utility is removed,

Please define “utility”. [do you mean a module? a program? under RISC OS, “utility” has a specific meaning in itself]

If we are talking about a module, it is the responsibility of the module to clear up any aliases it has set. If something external set up aliases, then it is the responsibility of that to handle the situation. If we are talking about a module, there is no such thing as unlinked help. It is contained within the module, or as a messages file (added to ResourceFS).

If a program… Programs do not link into the *Help system. They can provide help (-h or the like), but like anything else to do with the program, when it is done, it has gone.

Just to be clear:.Programs are not Modules.

nor another use for package manager.

Huh?

I think the double — will be around for a long time, it is used throughout gcc, autoconfig etc quite heavily.

Yup. All Unixy stuff, that. There is a fair amount of evidence laced through RISC OS itself to show that a single “-” is what is used. It’s our convention, just as a “/” is DOS/Windows convention, and “-”/“—” is Unix convention.

Edit: quite often entering a binary name without an argument will return either useage info or the help text, one example I can think of is *Fat32Format. Possibly this is the most user friendly way of assigning help to a command,

Depends upon the quality of the port. I have seen a fair number of appalling ports where the person has done little other than recompile it with RISC OS tools. So you run the program and it sits there doing absolutely nothing because the default no-options behaviour is to assume that something will be coming via stdin. Sorry, RISC OS just doesn’t work like that.

You might have guessed, I believe an honest port of something should bend the something to fit the conventions on the host system, not attempt to bend the host system to fit an alien set of ideas. But, hey, this is getting off topic.

Command line programs typically read arguments to tell them what to do, and it is usual if no arguments are given, to react in a manner similar to the built-in commands and say something like:
Syntax: MyCommand <file> [-option]
A complicated program may prompt with varying levels of help (like the assembler/compiler/linker), or may ask you to enter “-help” for details. Depends upon the program and how it is likely to be used, how much guidance is given. For example, my ResFinder (discussed in the forums a week or two back) only gives a basic syntax prompt, it is intended to be put in place by the programmer and then left alone.

though there may be BASIC utilities that would go off and do something other than providing info if you simply entered their name.

Depends upon what the program is. In a fair few cases, it is reasonable to expect that the program just goes and does what it is supposed to do. I don’t tend to like software that makes assumptions, however there are times when assumptions are okay. Like a program of mine called “ListFiles”. When you run it, it doesn’t tell you what it does (clue in the name!), it just goes and lists all the open files.
[note to self: get around to doing a prompt mode to allow files to be closed!]
Again, it depends upon the complexity of the program. In this case, anything other than “doing its job” would be annoying, and it accepts no parameters, so… going and doing what it should is therefore the only logical behaviour.

Yes Rick, we are talking about modules vs programs, I shouldn’t have used the term utility. Aside from that, where does Filetype utility come into the picture? I dont think they are modules yet clearly have a RISC OS distinction.

Regarding the behaviour of BASIC (or any) programs, probably for a bit of stdout stuff it isn’t important, but something more and I guess a form of identification(help) or syntax useage would make sense. A BASIC or LUA program can be opened readily in an editor to read some remarks, not so a C binary. You are right that some linux binaries do wait for stdin (cat from memory and some others), the only clue is that the normal prompt hasn’t returned, which is OK to a point, this condition would be shared by a program doing a lengthy operation, unless a programmer sends progress messages. It’s possible cat and friends do it this way so that unwanted stuff isn’t included when using CLI redirection and pipes.

where does Filetype utility come into the picture?

They are position-independent lumps of code, loaded by the OS into the RMA and given a small stack there, too. So they’re not modules, because once they’re done, they’re removed, and they’re not applications, because they don’t need to be paged into the application slot.

I then call ps2pdf to convert the ps file to a PDF–again, this works, but I’d like to be able to tell whether ps2pdf exists and, if it doesn’t, to do something graceful like display an error box. The Dr Wimp program calls an obey file which calls lout and ps2pdf as and when needed.

As ps2pdf is provided by Ghostscript then it may be sufficient simply to check for Ghostscript itself by attempting to read its System Variable Ghostscript$Dir. Ghostscript will be present if it is installed in its default location of !Boot.Resources. ps2pdf’s alias could also be looked for.

In an Obey file :-

If "<Ghostscript$Dir>" = "" Then Error Ghostscript not found
If "<alias$ps2pdf>" = "" Then Error ps2pdf not found

Or in BASIC :-

REM >ReasSysVar
DIM buf% 256
PRINT FNreadSysVar("Ghostscript$Dir")
PRINT FNreadSysVar("alias$ps2pdf")
END
:
DEF FNreadSysVar(SysVar$)
LOCAL len%
SYS "XOS_ReadVarVal",SysVar$,buf%,1<<31,0 TO ,,len%
IF len%=0 THEN ERROR 1,SysVar$+" not set"
len%=-len%
SYS "OS_ReadVarVal",SysVar$,buf%,256,0 TO ,,len%
IF len%>255 THEN ERROR 1,"Buffer too short"
buf%?len%=13
=$buf%

Because it matches the command name not the module name.

Must provide a command.

I think it might be useful to point out that *Help can be provided by a module for any keyword, not just for commands, and it also displays module help.

Here are some other things that came to mind:

• It is possible to for a help response to be more than a string, but to call code.
• Help keywords can be abbreviated and will display help on all the matches. Try ‘*h..’ ;-)
• A help string can be a MessageTrans token that is looked up in a Messages file in ResourceFS, which allows for internationalisation.

I think it might be useful to point out that *Help can be provided by a module for any keyword, not just for commands, and it also displays module help.

Which naturally makes us think about adding a Help2 module that can provide help for other commands, added by calls to Help2.

But when is the help searched for? If the help text of a module (in this case Help2) is changed, will a subsequent help call find updated text – or is it cached somewhere?

So it does, Steve. *Help IfThere is working here. I wonder how that works.
Edit: oh it must be in a module now, *Help doesn’t work for other Utilities in the Library.
The module help system is self contained, a standalone program can have self contained help, A new supporting help system would require management.

To find where a *command comes from, a module, alias, or Run$Path, try which 1.2 . It is not ARMv7 but does come with source.

I’ve not tried that Which, but there’s another here which is great. Brilliantly useful utility.

I really do think which, where and a number of other utilities should be built into the ROM!
Off the top of my head: keyboard emulation of mouse.
n.b. I don’t mean disc image as these sort of facilities may be required when no disc image is available.

I really do think which, where and a number of other utilities should be built into the ROM!

I do agree. At least then if a user reports a problem he can be asked to type *where and report the outcome without having to explain where where is.