Conference bulova::decw_jan-89_to_nov-90

  I think it's not so much a problem as a difference of opinion...

  I think what Mail did was nifty.  Notes apparantly didn't think of it,
  or haven't had time to get around to it, or both.

  A wishlist item to Notes is probably in order..

>Is this a problem in Mail, Notes, or user/RTFM?
    
    The global selection mechanism that you refer to (the MB3 paste) is
    subject to interpretation.  The application owning the global selection
    is asked for the contents of the global selection by the application
    wanting the global selection.  It's not something managed by the
    server.  In this case, Notes asks Mail.  Mail can reply with anything
    it likes.  Apparently, they have decided that selecting a mail message
    means selecting the content of the mail message.
    
    It could just as easily have replied with the string "Go away, I want
    to be alone." or the number of the mail message, etc.

John

It seems to me that mail's action is not intuitive; what I normally expect
is a representation of what I see on the screen copied.  For example, consider
what a quick copy of VUE's file list gives you (expanded file specs).  Should
VUE do the same thing as MAIL?  I think not ?

However, I'm not arguing that MAIL should change, either.  I'll have to try it;
it seems very useful.

>It seems to me that mail's action is not intuitive; what I normally expect
>is a representation of what I see on the screen copied.
    
    This is prime material for a rathole.  :)
    
    What is intuitive is what you expect.  What you expect is what you've
    seen.  What you've seen is simpleminded use of the global selection
    mechanism.  There isn't much abstraction in our application user
    interfaces.  This generally leaves us with just copying text around.
    
>However, I'm not arguing that MAIL should change, either.  I'll have to try it;
>it seems very useful.
    
    Agreed.  Too bad I don't bother with any DECwindows applications except
    DECterm and DECwrite...
    
John

When I implemented this function for Notes, we considered doing what mail
did, but after consulting with the SUE group we decided to only return the
text that was selected.  The global selection mechanism is very general and
when all DEC applications start handling more than just text, it will be
much more powerful.  

Currently, if you want to copy the entire note text all you have to do is
bring up the read window an select the "Select All" option under the Edit menu.

-Jer

	There was a discussion way back when in the XUI (then UID) conference,
	and the general consensus was that that directory line wasn't so
	much a piece of text but a representation of an object (specifically,
	a mail message). When you select a line in the index and choose
	an operation that acts on the selection (such as Move), it acts
	on the message, not the line of the index. Therefore, it seems
	consistent that when another application asks for the global
	selection, it should receive the selected item rather than the
	text of the index line. So, that's how we did it.

	Another aspect of the power of this method - you can select
	several messages with Shift-MB1 and paste them all in one
	fell swoop with MB3. I've used this on occasion to forward
	a Mail conversation to someone, or to gather related mail
	messages into a single file for convenience. An inconsistency
	is that selecting a folder or drawer and trying to paste it
	only copies the name of the folder or drawer, not the entire
	contents (in this case, the cost of accidentally hitting MB3
	is too high).

	Mike

<rathole alert>

While Mail is free to interpret GS in the way that it does, there is a 
possibility that a user get results which are entirely unexpected with 
possibly disasterous consequences. The scenario goes as follows:

User logs in, creates ususal complement of terminals emualtors and decwindows
native applications one of which is mail. 

User selects a mail message, read the text in which there are DCL commands
embedded. 

User decides they need do to something in the terminal emualtor window. User
reaches for mouse, bumps mouse to termnial emulator window and presses what 
they think is MB1 for focus. They actually hit MB3, causing contents of mail
message to be spewed to terminal. Most lines will be disregareded as garbage 
by DCL but the one or two lines which contain valid DCL will try to execute. 
Depending upon the command, the result could be disasterous. Suppose the message
contained instructions on how to clean out a directory - $DELETE *.*

I know that I'm talking about an error condition, but good human interface 
design also takes this into account. User errors are unavoidable and you must
build the system such that the system/interface minimizes the possibility
for errors.

<end rathole>

 

    Re .7:

    This is certainly not a new problem. With character cell VAX mail, it's
    very easy to mail a file to someone, ask that person to EXTRACT the
    mail, and TYPE the resulting file (not EXECUTE it): just typing the
    file will cause some DCL to be executed wiping out directories and
    files. One of my fellow colleagues showed me the hack, and it sure is a
    very dangerous thing.

    The bottom line is that it's easy to screw up things, and DECwindows
    mail isn't more guilty that anybody else. If only all DECwindows
    applications had followed DECwindows mail's lead (there is a lot of
    things that DECwindows mail can do with global selection that can't be
    seen yet), DECwindows would be even more impressive than it is.

    Denis.

	re .7: And the potential problem certainly isn't restricted to
	selecting a mail message - I would imagine it would be more
	likely to happen by selecting a few lines from a DECterm
	window, or a .COM file being displayed in an editor somewhere.
	I quite often do this to re-execute a set of commands, but that
	set of commands which may do exactly what I need done in one
	DECterm window might be disastrous in another. Them's the breaks...
	The only thing that might help would be a way to stop the paste
	after it has started on the receive end (no, ^X won't do it,
	unfortunately - you have to wait for the whole thing to type
	out).

	Mike

The one that causes the most damage to ME is when I accidently move the
mouse and select an extra line while in the process of releasing MB3.

    I find it hard to believe that TYPING a file can cause any DCL from that
    file to be executed.  If you type in the wrong thing to a $INQUIRE, maybe.
    If you do a $WRITE (DCL) of the wrong thing, maybe.  But not TYPE.
    
    Can anyone show a reproducible example of this behavior?
    
    Burns
    

>>>>Can anyone show a reproducible example of this behavior?

    If you can, DON'T POST IT HERE!  Use MAIL or the telephone to
    explain this.  Procedures which even potentially show a security
    hole shouldn't be posted in a public NOTES file.

re .-1

Heavens, no!  Don't post it here!  If you posted it here, then we might
learn what the problem is and be able to discuss it intelligently.  Much 
better to keep it in the dark so that vague mumblings about "dangerous
TYPE commands" can traverse the network and cause all manner of
uninformed speculation.

>>    I find it hard to believe that TYPING a file can cause any DCL from that
>>    file to be executed.  If you type in the wrong thing to a $INQUIRE, maybe.
>>    If you do a $WRITE (DCL) of the wrong thing, maybe.  But not TYPE.
>>    
>>    Can anyone show a reproducible example of this behavior?

Security holes like this one should not be posted in Notes files, but
overconfidence is a step on the way to destruction.

Suffice it to say that I know of at least one way to do this (using TYPE).
It depends on the type of terminal being used, and as far as I know,
it cannot be done to a DECwindows DECterm.

-steve-

    BTW,
    The example I got in the mail depended on tricking the user (by means of
    authoritative sounding directions) into entering the TYPE command
    indirectly.
    
    Burns