[comp.sys.amiga.tech] A bug in ARP 1.3?

lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/10/89)

In <14752@boulder.Colorado.EDU>, hunt@boulder.Colorado.EDU (HUNT LEE CAMERON) writes:
>I ran into what I perceived as a bug in ARP 1.3 a few months ago and
>forgot about it until now (when your hard disk gets trashed you forget
>about a lot of things).  Anywho, has anybody been able to make a file or
>directory called 'a' under ARP 1.3 and consequently tried to delete it?
>Using ARP's delete the file won't go away, but ol' AmigaDOS's delete will
>get rid of it.  Has anybody else seen this?

The letter 'a' is a keyword for 'ask'. Try...

del "a"

-larry

--
" All I ask of my body is that it carry around my head."
         - Thomas Alva Edison -
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+

hunt@boulder.Colorado.EDU (HUNT LEE CAMERON) (12/10/89)

I ran into what I perceived as a bug in ARP 1.3 a few months ago and
forgot about it until now (when your hard disk gets trashed you forget
about a lot of things).  Anywho, has anybody been able to make a file or
directory called 'a' under ARP 1.3 and consequently tried to delete it?
Using ARP's delete the file won't go away, but ol' AmigaDOS's delete will
get rid of it.  Has anybody else seen this?

--Lee

uucp: ...!ncar!boulder!spot!hunt
 

lindwall@beowulf.ucsd.edu (John Lindwall) (12/10/89)

In article <14752@boulder.Colorado.EDU> hunt@spot.Colorado.EDU (HUNT LEE CAMERON) writes:
>Anywho, has anybody been able to make a file or
>directory called 'a' under ARP 1.3 and consequently tried to delete it?
>Using ARP's delete the file won't go away, but ol' AmigaDOS's delete will
>get rid of it.  Has anybody else seen this?
>

The delete command is interpreting your a as the abreviation for the ASK
keyword, instead of as a filename.  The ASK keyword is neat - you could say

delete #? a

and delete will prompt you for each file or directory

"Delete foo?"

Like rm -i on Un*x.  To get help with ARP commands, type CommandName ?
and a short template is printed.  A second ? gets you a second (more
Un*x-like usage message).

To get rid of the file called a, use   delete "a".
John Lindwall

John Lindwall			lindwall@cs.ucsd.edu

barrett@jhunix.HCF.JHU.EDU (Dan Barrett) (12/11/89)

In article <14752@boulder.Colorado.EDU> hunt@spot.Colorado.EDU (HUNT LEE CAMERON) writes:
>has anybody been able to make a file or
>directory called 'a' under ARP 1.3 and consequently tried to delete it?

	Try:		1> delete "a"

	I guess that the ARP delete program thinks "a" is the beginning of
a keyword like "all" or "ask".

	This is a problem inherent in all command-line parsing in which
special keywords are not preceded by some sort of switch character.
For example, try creating a file called "dates" and then listing it:

		1> list dates

"dates" is a special keyword for the "list" program.  Yuck!!!

                                                        Dan

 //////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Dan Barrett, Department of Computer Science          Baltimore, MD  21218 |
| INTERNET:   barrett@cs.jhu.edu           | UUCP:   barrett@jhunix.UUCP    |
| COMPUSERVE: >internet:barrett@cs.jhu.edu | BITNET: barrett@jhuvms.bitnet  |
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////

bill@NCoast.ORG (Bill Hogsett) (12/11/89)

	I just deleted a directory and file named a using the arp
1.3 delete command.  The only way to do it is to use the full path 
as the argument to delete rather than just "delete a".  If I just did
"delete a" the program responded "Nothing to delete".  

	Looks like a minor bug to me.

-- 
************************************************************************
Bill Hogsett                    CLEVELAND AREA-AMIGA USERS' GROUP
ncoast!bill                     (216) 292-4404 (BBS)
ncoast!wfhami!bill
20876 Almar Dr.	
Shaker Heights, OH 44122        I get paid for my legal opinions, but

wfh58@leah.Albany.Edu (William F. Hammond) (12/11/89)

In article <1989Dec10.195003.10146@NCoast.ORG>, bill@NCoast.ORG (Bill Hogsett) writes:
> 
> 	I just deleted a directory and file named a using the arp
> 1.3 delete command.  The only way to do it is to use the full path 
> as the argument to delete rather than just "delete a".  If I just did
> "delete a" the program responded "Nothing to delete".  
> 
***
"A=ASK" is a keyword for interactive-query deleting.

Thus, the command

   delete a *

will query you about deletion of every file in the current directory.  If
you simply want to delete a file in the current directory named "a", then
enclose the filename in quotes:

   delete "a"
------------------------------------------------------------------------
William F. Hammond                   Dept. of Mathematics & Statistics
518-442-4625                         SUNYA, Albany, NY 12222
wfh58@leah.albany.edu                wfh58@albnyvms.bitnet
-------------------------------------------------------------------------

castong@bucsb.UUCP (Paul Castonguay) (12/13/89)

What does the following line mean?

    Wait(1 << Window->UserPort->mp_SigBit)

I know it causes my program to wait for a response in the IDCMP port,
but how exactly does this work?

->  means structure member notation for pointers

<<  means shift left, a bitwise operator, which can also be enterpreted
    as multiplication by 2

So, why should shifting the mp_SigBit member of the window's UserPort
one bit position to the left magically cause my application to wake up 
from a sleeping condition and recognize the presence of an incoming message?

                                  -Paul Castonguay

guineau@wjg.enet.dec.com (12/14/89)

> What does the following line mean?
>
>     Wait(1 << Window->UserPort->mp_SigBit)
>
> I know it causes my program to wait for a response in the IDCMP port,
> but how exactly does this work?
>
> ->  means structure member notation for pointers
>
> <<  means shift left, a bitwise operator, which can also be enterpreted
>    as multiplication by 2
>
> So, why should shifting the mp_SigBit member of the window's UserPort
>  One bit position to the left magically cause my application to wake up 
> from a sleeping condition and recognize the presence of an incoming message?


It doesn't. The   << (and >>)  C operators mean 

	a << b

Shift a left by b bit positions.  (shift right for >> )

So  Wait(1 << Window->UserPort->mp_SigBit)

means shift a 1 left to the position corresponding to the signal number.
So for example
an  mp_SigBit of 3 coresponds to a bit mask of  binary  1000 (i.e. bit
position 3).

Wait needs a bit mask, while mp_SigBit is the signal number.

>                                 -Paul Castonguay


John Guineau

bevis@EE.ECN.PURDUE.EDU (Jeff Bevis) (12/15/89)

In article <148@bucsb.UUCP>, castong@bucsb.bu.edu (paul castonguay) writes:
>What does the following line mean?
>
>    Wait(1 << Window->UserPort->mp_SigBit)
>
Actually, the '1<<N' means "shift 1 to the left by N bits," which can be
interpreted as a multiplication by 2^N.  Having said that, the result of
this expression probably will be much clearer.  The mp_SigBit is the bit
*number* of the signal bit assigned to this message port, which you will
Wait() on for messages.  You can wait on one or many signals simultaneously
by passing a bit *mask* (or, in exec-ese, a mask of *flags*) to Wait().
However, sing mp_SigBit is not a *mask* (ie, a single 1 in a longword of 0's),
you need to convert it to such, and then pass it to Wait().  That is what
the line in question does.  Then, exec causes your task to be suspended
until that signal bit becomes active (ie, a message is sent to your window's
message port), and then you awaken.

Hope this helps.

+--------------------------------+--------------------------------------------+
| Jeff Bevis 		         | "But I don't like spam!"		      |
| bevis@en.ecn.purdue.edu	 | 	     Give me Amiga or nothing at all. |
+--------------------------------+--------------------------------------------+

aduncan@rhea.trl.oz.au (Allan Duncan) (12/18/89)

> "delete a" the program responded "Nothing to delete".  
> 
> 	Looks like a minor bug to me.
> 

The filename a that you give is also a keyword for all.  Try
delete "a"
and you will find that it works.

Allan Duncan	ACSnet	aduncan@rhea.trl.oz
		ARPA	aduncan%rhea.trl.oz.au@uunet.uu.net
		UUCP	{uunet,hplabs,ukc}!munnari!rhea.trl.oz.au!aduncan
Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.