| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 226.1 | Get the new executable | CGFSV1::DREW | Steve Drew | Fri Dec 19 1986 21:03 | 15 |
|
> I believe a new version is available for V1.2 from
>
> CGFSV1::DISK$73G:[DREW.SHELL]SHELL_AMIGA.12
Yes your right I just put a new version of shell in my account
as mentioned .0, And to clearify the disk trashing bug should be
fixed in that version. It was a weird bug under 1.2 workbench that
would trash the root directory and I have now worked around that.
I Would strongly recommend anyone using my Shell_amiga under 1.2
that you copy this new version before any disk's get blown away.
Diskdoctor will fix these disk's up although the directory structure
will probably be gone.
/Steve.
|
| 226.2 | Drubbed Again | AUTHOR::MACDONALD | CUP/ML | Tue Dec 23 1986 19:00 | 2 |
| Hmmm, I think the new version of the shell may have trashed my
Workbench diskette last night. Any other reports?
|
| 226.3 | Are you sure? | CGFSV1::DREW | Steve Drew | Tue Dec 23 1986 21:02 | 15 |
|
What were you doing at the time. The symtom that I fixed under
shell (which was not a problem with shell, but 1.2 wb) would
trash track 40 surf 0. This will show up when you run diskdoctor.
Of course the error would only occurr when writing eg. mkdir, copy,
ect..
I have read reports on the USENET that people have had disk trashing
under VT100, so we really need to clarify in each case what we were
doing and where the disk went bad. If this is a bug under 1.2 wb
then any program would have the potential to cause disk trashing.
I have not had any problems since patching shell, previously I had
about 6-7 disks trashed over about a 2 month period.
/Steve.
|
| 226.4 | | AUTHOR::MACDONALD | CUP/ML | Tue Dec 23 1986 22:49 | 20 |
| I should have checked the disk with diskdoctor, but I grabbed my
backup and duped it instead. I was using makedir and copy (I was
setting up a ram:c directory at the time and copying the contents
of sys:c to ram:c). Then I tried running a program which requires
something from the Wb diskette to work. That's when I got some Guru
Med errors:
0000000B.0022176E
I tried again
00000004.0023B886
and again
0000000B.00241886
I finally grabbed the WB backup and things ran fine.
Paul
|
| 226.5 | Sound's different | CGFSV1::DREW | Steve Drew | Wed Dec 24 1986 15:10 | 8 |
|
Does'nt sound like the shell bug. (relief) It would complain about a
read error and then not be able to validate the disk.
If you were'nt actually writing to your wb disk then it may of
just went bad. Although cant see why you would get guru's rather
than read/errors.
/Steve.
|
| 226.6 | Problem DOES Exist | AUTHOR::MACDONALD | | Wed Jan 14 1987 11:38 | 13 |
| Well it happened again (and it appears to be repeatable) ...
Using VT100 running it from the Shell, Workbench disk in DF0: and
a blank unformatted disk in DF1:. I pop the CLI screen to the front
and format the DF1: disk. Then I copy files over to DF1: from RAM:
where I had originally downloaded them with VT100. Voila ... READ
error on DF1:. Only seems to happen with the Shell.
I am using 2 MB RAM: but don't think that should impact anything.
What say Drew?
Paul
|
| 226.7 | Lets make sure. | CGFSV1::DREW | Steve Drew | Thu Jan 15 1987 14:13 | 26 |
|
Paul, since fixing the problem (I thought) with shell I have
still not had any disk's trashed, nor have any one of about
7-8 people locally here, or any one the Usenet (that they've
mentioned).
The part of the code were the disk's were becoming trashed was
just the prompt "$ " was printed after completing the previous
command. If your read error came up just after the prompt was
printed then there could still be a problem in shell. If you
got the read error during the copy from ram: to df1: and shell
was still in the copy routine (prompt not printed) then you
must of had a real read error.
Questions:
when you were copying the files from ram: to df1: was
vt100 still transfering files to ram?
Can you reproduce it on your other drive?
Gotta ask, you did get my fixed version , right?
I've just about finished my next version with more goodies as
well as rewritten copy command (by matt).
Maybe you could VaxMail me on this one.
Steve Drew.
|
| 226.8 | KEY BINDING PROBLEM | POLAR::GOSLING | | Mon Jan 19 1987 14:26 | 50 |
|
Glad I have haven't been hit by Paul's problem, but I do have a
problem associated with binding an activity to a function key.
Yesterday, I started the process of upgrading my disks to V1.2 -
lots of fun. While I was going through the process and looking at
the Shell (2.04m) documentation I remembered that I could save a
few key-strokes by binding a couple of the repetative chores to
the function keys.
The command I tried to bind was the "format" command to key F1,
making the entry as follows:
set F1 "FORMAT DRIVE DF1: NAME \"V1_2 EMPTY\""
When I typed "set" it appeared in the list of set parameters.
However, when I pressed F1 (shift/f1) it came back with the
following (or something close - but I'm sure you get the idea):
usage:sys:system/FORMAT DRIVE <DRIVE> NAME <NAME> [NOICONS]
This indicates to me that I screwed up somewhere in the syntax
during the "set" process!?
I went through the "set" process a number of times, changing the
case of the key words, thinking that that may be the problem - no
luck!
After playing with this for a while, and wanting to get on with
the upgrade process, I invoked the same command at the "$" prompt
and got the same 'usage' message. Eventually I quit out of Shell
and entered the command from CLI and the formating worked -
proving the syntax.
Funny thing, if I restart the Shell again, I can invoke the format
command at the "$" prompt and have it work, but after doing the
"set F1" ditty, I can't get "format" to work no how, without
moving out to CLI.
Note that I don't have 'format' "set" or "alias'ed" anywhere in my
initialization file (I checked, because I thought that may cause
it to get caught up in its own shorts).
Any ideas?
Thanks,
Art
|
| 226.9 | Zappppp | AUTHOR::MACDONALD | | Mon Jan 19 1987 16:15 | 12 |
| The problem struck me again yesterday .. same scenario as before.
Fortunately I was able to recoveer the disk with diskdoctor. Zap
was on Track 40 Surface 0.
VT100 in the background (RUN VT100.24 from the shell), and a COPY
from RAM: to DF1: from within the SHELL. Three times couldn't be
a coincidence!
Paul
P.S. Drew, I am using V2.04 for the Amiga 1.2
|
| 226.10 | You can call me Steve. :-) | CGFSV1::DREW | Steve Drew | Wed Jan 21 1987 01:29 | 43 |
|
re: .8
Art here's the problem, it's all to do with shell's handling of
quotes and spaces, each time a command goes through the interpreter
the quotes get removed.
Your cmd:
set F1 "FORMAT DRIVE DF1: NAME \"V1_2 EMPTY\""
set's F1 to FORMAT DRIVE DF1: NAME "V1_2 EMPTY"
When you hit F1 it goes through the parser again and
then looks like this:
FORMAT DRIVE DF1: NAME V1_2 EMPTY
this would be fine for a internal shell command since
it knows that V1_2 EMPTY is one argument but when it calls
format command it wants quotes else it assumes 2 arguments
thus the error message.
If you want to set this command to a key you need to insert
the overide character it's self via a '\\' you would then
end up with:
set F1 FORMAT DRIVE DF1: NAME \\\"V1_2 EMPTY\\\"
typing set F1
would show you:
F1 FORMAT DRIVE DF1: NAME \"V1_2 EMPTY\"
re: .9
Paul;
Please, I can not help you with your problem unless you
supply the information I had requested in .7, It's not
worth me putting in alot of time into it until then.
I will make version 2.05M available probably tomorrow,
I suggest you try that and if you continue to have problems
answer .7 and I will look into it. Have you tried not
using shell for a while (days...) to make sure you dont
have a drive problem??
/Steve
|