[comp.unix.xenix] SCO's vsh

root@ozdaltx.UUCP (root) (02/10/90)

I've been toying with vsh (visual shell) on SCO Xenix (286)
and get the impression that it will allow customized menus/help for
specific uses.  The manual hints that this is possible, but dosn't go
into any specifics outside of basically listing overall commands.

Can anyone enlighten me further if this is possible or how flexable
vsh really is?
thanks....
Scotty
------
AIDS INFORMATION EXCHANGE BBS      (214) 247-2367/247-5609
               "Education is the best weapon"
     {ames,rutgers,texsun,smu}!attctc!ozdaltx!sysop 

soup@penrij.LS.COM (John Campbell) (02/12/90)

In article <5904@ozdaltx.UUCP>, root@ozdaltx.UUCP (root) writes:
> I've been toying with vsh (visual shell) on SCO Xenix (286)
> and get the impression that it will allow customized menus/help for
> specific uses.  The manual hints that this is possible, but dosn't go
> into any specifics outside of basically listing overall commands.

	Yeah, I know.  The manual is _really_ incomplete.  Few people
	know (or want to know) how to do this stuff.  I imagine that
	it'd be possible, but, considering that the shell is not
	supposed to require a user's manual, I found a couple of blind
	alleys that forced me to kill it from another terminal.

	I _did_not_ like the vsh, but then, I'm a programmer, right?
	I actually find the ksh indispensable, so anytime I end up on
	a new machine I port it over...

> Can anyone enlighten me further if this is possible or how flexable
> vsh really is?

	Like my summary, vsh emulates intergalactic vacuum.  It's really
	pretty good at it, too...

--
 John R. Campbell	...!uunet!lgnp1!penrij!soup	  (soup@penrij.LS.COM)
		 "In /dev/null no one can hear you scream"

lebo@enea.se (Lennart Boss`r) (02/26/90)

In article <5904@ozdaltx.UUCP>, root@ozdaltx.UUCP (root) writes:
> I've been toying with vsh (visual shell) on SCO Xenix (286)
> and get the impression that it will allow customized menus/help for
> specific uses.  The manual hints that this is possible, but dosn't go
> into any specifics outside of basically listing overall commands.

> Can anyone enlighten me further if this is possible or how flexable
> vsh really is?

In article <103@penrij.LS.COM>, John Campbell writes
>I _did_not_ like the vsh, but then, I'm a programmer, right?
>I actually find the ksh indispensable, so anytime I end up on
>a new machine I port it over...
>Like my summary, vsh emulates intergalactic vacuum.  It's really
>pretty good at it, too...


I have used vsh as a user interface for not-to-experienced users,
building customized menu systems for them. I found vsh quite good for
that purpose. As mentioned by the earlier contributors, the
documentation is _all_but_nonexistent_. I had the luck of finding
some old manuals, one from about 1984 for the IBM/Microsoft XENIX
3.0 and one for a XENIX verision for Altos computers. Those
manuals gave a better but by no means complete description of
how to customize the visual shell. Since I live in Sweden, I made
a try of changing the menu texts and help texts to Swedish and
succeded (much to my own astonishment). So I started playing around
trial-and-error and found that "vsh" could be customized quite a lot.

By the way, root@ozdaltx.UUCP, I tried to mail you about this but
it bounced, so I hope you read this posting.


-------------------------

The menu system in vsh is described by text files that can be edited.

/usr/lib/vsh/menu.def   is the file describing the main menu tree.
/usr/lib/vsh/VSHELL.HPT is the on-line help texts
/usr/lib/vsh/VSHELL.HPP is a non-ascii file with pointers to various
			seek points in the VSHELL.HPT file. This file
			is refreshed automatically when "root" uses
			the menu system and issues a HELP command.
			(On-line help wont work until "root" has
			 done this)
/usr/lib/vsh/*.mnu	User supplied "bottom-level" menus. These
			menus form the leaves of the menu tree and
			are used as simple "forms" for collecting
			parameters and selecting options.



What you can do for customizing vsh:
------------------------------------


1) You can edit the /usr/lib/vsh/menu.def file and build a 
   completely new menu tree. 

	The lines you would most often want to edit is in the last 
	50 lines or so in the file, starting after the text
        "COMMAND=" and ending with the text "HELP=". These lines
        defines the menu structure. The syntax is undocumented but
	simple, I'll try to examplify below:

	COMMAND=
		name1 command1
		name2 command2
		name3 =
			name31 command31
			name32 =
				name321 command321
				...
			^
			name33 command4
			...
		^
		name4 command4
		...
	^

	nameX is the name of the menu item appearing on the screen,
	it may refer to a simple command or a submenu. 
	COMMAND is the name of the root menu (may be changed)

	commandX is the name of the command to perform when the
	menu item is selected. It can be a Unix command name (use full
	path names for clearity and unambiguosness), the name of a
	built-in command (those are specified earlier in the
        menu.def file) or the name of a *.mnu file in the
	/usr/lib/vsh directory (suffix .mnu shall be omitted)

	The characters "=" and "^" fills the function of "braces" for
	each menu subtree level. You can use indentation for
	clearity as examplified above (one more undocumented feature). 


2) You can place (different) copies of the menu.def file in the
   users home directories, to give them personalized menus.
   This menu.def file will be selected by default if it exists.

3) You can change built-in commands and defaults in the menu.def
   files. (Be careful though)

4) You can run any shell command from within vsh

5) You can fork to other shells (sh,csh or even vsh)

6) You can create your own *.mnu files for collecting input to
   your own commands. 

	These possibilities are extensive
   	and it is to much to present here. I will gladly submit a
   	follow-up if anyone is interested. In short you get an
   	input-form feature with argument checking and editing 
	possibilities. You can check for numeric, file-name,
	directory-name, filename-list and free form arguments.
	You can define a parameter as a select field, and 
	specify defaults for parameters and whether parameters
	are mandatory or optional. On-line help text can
	be submitted.

	The *.mnu files are essential if you want to customize
	you menu system. But it should take about 5 pages to
	give a decent description of them (and some of my
	valuable time too). Mail me if interested. 
	 
7) You can change the built-in prompts and error messages

	Not much need to do so for English speakers.

8) You can change the help texts for the on-line help

	Not much need to do so for English speakers.

9) You can add/remove/rename menu items from inside the menu
   system.

	But be careful! This feature is _unstable_ to say the
        least. Always backup the menu.def file before you
        try it. (Or even better, don't try at all)

9) Some other things I have surely forgotten.



What you can't do (as far as I have found out):
-----------------------------------------------
Actually this is not "cannot's" but "dont know how's". Most 
certainly it is decribed in the dusty volumes of documentation
hidden somewhere, presumably in some attic at Microsoft Inc.


1) You can't get one level up when you leave a submenu. You always
   return to the root menu. This is _very_ awkward if you have a
   deeply nested menu system, but can be accepted for "flat" menu
   trees.

2) The access to environment and shell variables seems a bit
   restricted. This is mostly a feeling I have, I have not made
   much testing of what can be/cant be done.

3) You can not put the *.mnu files in the users directories, even
   if the manuals claims that this is possible. They must be
   placed in the /usr/lib/vsh directory. Perhaps there is some
   undocumented "trick" that must be performed if you want these
   files to be found in user directories. eg. use of a .vshrc
   file (don't know if this is possible) or a VSHPATH variable
   setting or something similar.

4) The files window is _very_ slow for large directories. You should
   keep below 100 files/directory or so to get good performance.
   I suspect it is not a linear performance drop but worse.

5) You cant get the files ordered (eg. alphabetically) in the 
   files window. Files are listed in the order they appear in
   the directory slots. Period! 

6) It is hard to send wildcard characters as arguments to
   commands. Vsh itself performs wildcard expansion but 
   I have not figured out how to send a wildcard as an argument
   to a command.(No substantial restriction in most cases, I admit)
   
7) The size of the menu system is limited. I cannot give any exact
   figures and perhaps several factors interact. As far as I have
   found out you can expand the default menu tree with about 50%
   before you hit the roof. This is adequate for the purpose I
   have used vsh for, namely as an interface for non-experienced
   users. A too big menu system will yield an error message
   "Cannot load executable file" or something similar.

8) You can't change the keys used for certain functions.





PS to John Campbell.

"Intergalactic vaccum" is to put it a bit strong, but I understand
your point. I would never use "vsh" myself in my daily work! There
is a great difference between the needs of a Unix guru and a neophyte
though. (Has anyone seen a menu system suited for expert users?)




PS to SCO/Microsoft.

Shame on you for cutting down on the documentation about "vsh".
WHY?? 




PS to all Swedes.

Skicka mail om ni {r intresserade av en Svensk version av "vsh".
Jag har ett antal olika gamla versioner liggande.




Best regards,


Lennart Boss`r.		E-mail: lebo@enea.se

------------------------------------------------------------------
The opinions as expressed above are private, and not necessarily
shared by my employers - former, present or future.
------------------------------------------------------------------