#WShell + Opus + ToolsX
32 messages in this thread
I'm not exactly sure who to address this to, so I'm going to throw it
out to the general masses and hope someone can give me a clue…
I recently received my upgrade to WShell 2.0 (less than a week
turn-around – thanks Bill!), and after installing it, I've run into 2
seperate problems. Well, only one is a problem, the other an
inconvenience.
The "problem" is that I can no longer get Directory Opus to do any kind
of archive operation, mainly because I can't get it to open a shell window
to do it in. I've played with the DirOpus configuration options for the
past two days now, to no avail. It _will_ open a WShell on the Workbench
when I click on the RUN gadget, but any gadgets that cause a DirOpus script
to run (like archiving operations) no longer work. In fact, they hang
until I press SHIFT+ESC, but no shell window ever opens, not on the Opus
screen nor on Workbench. I don't know if I have the Opus configuration
wrong, or if I need to change something in my WShell configuration. Any
help would be greatly appreciated.
The "inconvenience" concerns the recently released ToolsX program
(SteveX's pgm to launch pgms from the WB2.0 Tools menu). After installing
WShell, every time something is launched from the Tools menu, a shell
window appears on my WB screen and stays there until I close it. As I
said, it's not really a problem, just an inconvenience. Any know how to
get rid of it?
I've been a WShell user for years now, and can't live without it. The
new version is really nice and I recommend it highly. If I have to live
with these problems, I will, but I'd really appreciate any advice any of
you may have that would help me rectify them. Thanks!
– via Whap!
Mike,
I don't know the answer to your problem with Opus, but the
inconvenience you mention regarding ToolsX is not a problem with wshell.
ToolsX opens the window whenever a program is launched to provide a CLI for
console input and output. Since ToolsX doesn't know whether a program will
require the console, it simply opens one for every program launched whether
it needs it or not. In that way, ToolsX doesn't need special code or
parameters to handle programs which would require the console.
Steven,
You mentioned that ToolsX opens a window for every program launched. It
didn't do this (for me) prior to installing WShell. Anyhow, Bill has
provided the solution, which was to turn off WShell's ECHO environment
variable. I did that, and now the windows have stopped popping up. My
thanks to both of you for your help.
Mike
– via Whap!
Mike,
Hmmm, that's interesting because I have ECHO set to OFF and the
window still opens. Wonder why?
Steven,
Well, maybe it wasn't the ECHO that fixed it. At the time, I also
stopped using WShell with the CON: device. I use the CNC: device for all
my shells, so I really didn't need to use it with CON: anyway. Frankly, I
don't entirely understand the differences between the two devices, mostly
because I haven't had time to study the manual yet. I never used the CNC:
device until I started having trouble with the old version of WShell under
earlier versions of WB2.0. I remember Bill suggesting the switch back
then, and now the WShell 2.0 manual seems to use CNC: as its primary
device, so I've stuck with it. The manual also showed how to use it with
CON: by first dismounting it, then using the DHOpts command to assign it to
a WShell. Apparently that's what caused the problems with Opus, and maybe
with ToolsX too.
Anyhow, now I only have six WShell-related lines in my user-startup
file, which are:
DHOpts PIP: CNC:0/11/640/200/WShell/CLOSE MENU S:CNC-Menus
resident Shell l:wshellseg system pure
resident WShell l:wshellseg system pure
FComp
Newwsh
popcli 99999 newwsh
Actually, the main reason for these little problems I've been having is
probably because WShell 2.0 seems so different from previous releases, and
it's just going to take some time to become familiar with all of its many
features and how they work. In time, I'll get the hang of it.
Mike
– via Whap!
Mike,
Well, maybe when I get WShell 2.0 I'll have similar problems. I
use ToolsX, but even with the ECHO env variable set to OFF, the console
window still opens when I run a program from the Tools menu. I really
don't even know why I use ToolsX because I use BrowserII and ParM 3.0 which
really gives much greater flexibility than using the Tools menu.
Furthermore, both of these programs correctly launch a Workbench program.
I don't know if ToolsX correctly launches a Workbench program or is simply
running the program as though from a CLI, thus losing all .info based tool
items. My only concern about BrowserII and ParM is that they both utilize
arp.library and the req.library (the one used by Cygnus Ed). Both of these
libraries could have some incompatibilities with 2.0 (Idon't know that they
actually do, but neither of them were developed for 2.0.) I do know that I
may have some stuff that doesn't quite work right because I get occasional
GURUs or system hangs with stuff that never gave me any problem under 1.3.
I just don't know what stuff I use that's the culprit.
Steven,
I don't know if there are any problems with the arp.library under 2.0,
but I haven't run into any, nor have I heard of any yet. As for
req.library, that's been upgraded several times since the last release of
CED, and works quite well under 2.0. According to the version command, the
req.library I have is 2.2, which works fine for me, although I did see a
reference to a version 2.5 somewhere. Take a look in ASDG's library in
AmigaVend for the latest version.
The last batch of Fish disks I got (561-570) had another ToolsX-type
program on one of them, written by Nic Wilson (I think), which claimed the
ability to launch both CLI and Workbench programs from the Tools menu. I
haven't had the chance to check it out yet, but I do remember seeing
something about it while I was archiving the disks for our BBS. ToolsX
itself only launches programs as CLI/Shell processes, and I too want
something that will read and use any tooltypes I may have set from the
Workbench.
Mike
– via Whap!
I remember uploading the Nic Wilson program a few days ago, but I don't
recall the name of the program. It would be in AmigaTech, probably in the
System Utilities library.
Betty
ToolsX won't launch WB apps as though they were launched from WB – the
system doesn't provide any easy way to do that.
ToolsX is as system friendly as it can possibly be. There are very few
programs that take multi-selected icons as arguments but won't take command
line arguments.
Unfortunately DPaint is one of them.
…Steve
Now Mr. X, I am surprised at you. The technology for launching a WB
program is very well known. I put together a program called WBRun many,
many years ago that will correctly launch a WB program. If you want, I can
locate it for you, but thought that it made it onto one of the fish disks.
John A. Toebes, VIII – via Whap!
John, I wouldn't mind seeing the source for launching a WB program, too.
Although I understand the technique, I haven't had the time to sit down and
write one myself. (You know.. programmers are lazy by nature… most of
us, anyway 🙂
Khalid.
Khalid –
Is it possible (or will it be soon <grin>) to use your FR _directly_ to
launch a program, rather than to pick a file which is then "injected" into
a shell behind a "Run" command?
. . . . . JimDoc
Jim, no.. but it's a good idea.
ok.. I'll put it in.
Khalid.
John:
You're message about launching WB programs just reminded me of something I
had been meaning to look into. I saw your WBRun program a while ago and
learn't a lot from it, (Thanks!). One question though about 2.0. How are
you supposed to go about assigning the ProgDir: directory? WB programs that
depend on that assignment seem to have problems when launched from
something like WBRun.
Thanks,
-=Martin=-
– via Whap!
Well, it looks like it is time to update WBRun to handle it. It is just
the matter of passing one additional tag to CreateProc (actually
CreateNewProc) which specifies the home directory. Of course this only
works under 2.0.
John A. Toebes, VIII – via Whap!
John:
Thanks for the response. I just managed to get a copy of the new Includes
and Autodocs manual and see what you are talking about. Now if I can only
find a copy of the libraries manual…
Thanks again,
-=Martin=-
– via Whap!
Not to but in on this thread, but can you share the source of the Includes
and Autodocs Manual? I've been looking for it for a couple of weeks now,
unsuccessfully I might add.
Rodger
– via Whap!
Ah, well, if it's common knowledge then I'll add it to ToolsX.
It always seemed like the kind of thing that should be private to Workbench
– is it documented well enough to figure out, or is it voodoo like writing
filesystems used to be?
…Steve
If you think about it, it has to be common knowledge because the
application programs have to be able to get at the information. Just look
at the startup code for c.a and you will see what it does. As long as you
can replicate the environment by sending the same message in the same
format you will be fine.
John A. Toebes, VIII – via Whap!
What are your thoughts on the various WB tool managers: ToolX, ToolManager,
AdDTools and so on. Do you have any preferences?
Actually, I use none of them. I have a fairly vanilla system with the
exception of POPCLI (I consider Wshell to be part of a vanilla system). Of
course it helps that I can type pretty fast.
Steve,
Yep, I know that ToolsX won't do that. Although that's rarely an
essential need, some few programs are preferably launched in that fashion
to do such things as change stack size and/or pick up a tooltype. Thus,
the ability of toolstype programs like ToolsX to do that may be useful,
albeit not in most circumstances. I've been using your program for awhile,
however, and it's been quite useful, although I don't work exclusively from
the Workbench, so I only include tools in the menu where that facility
isn't needed. Most of the time I use BrowserII, which is a form of
dirutil, and the CLI. Workbench often seems less flexible for me, although
2.04 is a magnitude of improvement over 1.3.
ToolsX won't open a console window for a program, unless the program does
some output. The console ToolsX opens is a CON: window with the AUTO
option, meaning the window won't open unless there is something printed to
it.
If you redirect the output from the program you're running to NIL:, or it
never does any output, then there shouldn't be a window opened.
…Steve
Steve,
Well, there is one. Another user of WShell says that Bill Hawes
suggested turning the echo env: variable off. He says that worked for him,
but I have always had the env: variable set to off, but ToolsX still opens
the console window for every program run. Not that that is any major
problem. If a program needs it, then fine. If it isn't needed it does no
harm in being there. Apparently, from what this other fella said, the
window doesn't open under the AmigaDos shell, so it must be something
related to WShell. WShell doesn't support the AUTO feature, at least not
the present version, so perhaps that is the reason the window opens.
Steven,
Actually the old versions of WShell (ConMan actually) _do_ support autoopen
windows, and have since 1989, back when the AmigaDOS 2.0 software was still
in diapers. The option was called "deferred opening" and could be selected
on a device-by-device basis.
Not that this matters much now, as the the WSHell 2.0 software has a
greatly improved console handler with support for the 2.0-standard option
keywords, and many additional extensions.
-Bill Hawes
Bill,
How do I go about getting the upgrade for my WShell? I sent you E-mail
with my new current address a couple weeks ago after making a phone call to
you. What is the upgrade policy and costs?
thanks
Chris
Chris,
I updated my WShell customer files for your new address, and sent out a new
update notice card, so you should receive it soon.
-Bill Hawes
Mike:
I think I remember seeing a message posting by the author of Wshell, saying
something about addressing 'problems' w/WB 2.04… I don't use WShell, so I
don't remember too clearly what it was all about… but you might want to
do a keyword search in the libraries for "WSHELL" with age set at say 30
days to see if there are any patches or fixes available. Sorry I can't be
more specific.
– Whapp!ng from the North Coast Michael
Well I gues that answers that… like Gilda Radner used to say… "never
mind" 🙂
– Whapp!ng from the North Coast Michael
>…like Gilda Radner used to say… "never mind"
Mike,
On the contrary, I appreciate the effort. The things you mentioned had
to do with the previous version of WShell. The problems I referred to
concerned the latest version, 2.0, which was just recently released. In
both cases, the problem was not with WShell. The first was a bu-, uh,
inconsistency, in Directory Opus, the other was merely my own ignorance.
Both have been satisfactorily resolved, and everything is working just fine
now.
Thanks again,
Mike
– via Whap!
I use WShell myself, and haven't had any problems with ToolsX opening up
shell windows where there shouldn't be any.
What commands do you have ToolsX executing? Is WShell your resident user
shell? I can't think of what might not be causing it.
…Steve
Steve,
I have ToolsX running just about anything I use on a regular basis,
stuff I used to start from WB icons: Baud Bandit, Whap, ProPage, ADPro,
PCWindow, etc., etc. Selecting any of them would cause a shell window to
open, with the only line in the window being (for example):
++>Whap!
When Bill suggested turning off the ECHO, that made sense because that
one line looks like an echoed WShell command line. However, a simple
"setenv echo off" didn't fix the problem. I had to go in and turn off the
echo variable in both env: AND envarc: to get the windows to stop showing
up.
Yes, I am using WShell as my resident user shell, as well as my custom
shell. Both are configured in my user-startup file, as per the examples in
the WShell manual.
Mike
– via Whap!