Look, both DOS and Linux have their pluses and minues, in Linux you have
to be more careful [than in dos] when typing in commands, because a syntax
error can have very bad results.. DOS is not affected in the same way...
At 08:15 AM 9/7/00 +0200, you wrote:
>Steven wrote:
>>> This is a bug IMNSHO, a program should check to see
>>> that the input it gets is correct.
>>
>>Correct? What's correct? Is "del *.com" correct?
>>Is "format a:/u" correct? Is "deltree windows" correct?
>
>Perhaps I missunderstood but isn't the problem due to the fact that "dev"
>and whatever more it was didn't exist in the current directory? This is
>fairly easy for a program to test.
>
>You answered:
>> dd if=cdrom/Corel/Boot/boot1440.img of=dev/fd0
>
>You've left out the / in /cdrom and /dev.
>
>>Why pick on Linux? DOS is the same.
>
>NO IT IS NOT! If the user types in an incorrect syntax the program should
>NEVER EVER screw anything up - it should exit gracefully (or atleast not
>make any changes and hang). This is exactly what I want to point out - the
>Linux world obviously have trouble grasping this (not based on what you are
>answering of course but on how the program does). Without these easy checks
>it will not be popular (since it is unsafe). Frankly I don't care much, but
>you as a Linux user (and FANatic <g>) should IMO. Or is Linux only meant
>for some people?
>DOS is safe in the sense that you can never screw anything up by typing
>something that isn't according to the syntax. That you as a user can format
>the HD and other things is something else entirely (you can destroy things
>if you want to but never by incorrect syntax).
>
>>If a user makes a
>>mistake in a command, he can get a distructive result.
>
>True, but this is about syntax not the meaning of that syntax. If the user
>happens to give a command that is allowed then it's the users fault.
>
>>For example, if you carelessly hold down the shift key
>>while entering "del 8ball.com", you will delete every
>>com file in that directory. Try that in your root DOS
>>directory for some real fun.
>
>I will? I've never tried that, might I ask how that's going to happen?
>(And I can always undelete in DOS).
>Ok, here goes....
>
>C:\DOS\>DEL (BALL:COM
>No such file or directory
>C:\DOS\>DEL BALL:COM (using numeric 8)
>No such file or directory
>C:\DOS\>del 8ball.com (Shift-Enter)
>No such file or directory
>
>Perhaps you should start looking for viruses? Because DOS has never and
>will never act in the way you describe.
>
>Ok, you probably meant using a US keyboard, lets take a look (CTRL-ALT-F1):
>C:\DOS\>DEL *BALL>COM
>No such file or directory
>
>Obviously you haven't grasped how the * works in DOS and Linux. A
>momentarly failure in your own RAM perhaps since I'm positive you knew
>this. Only way to accidently remove all COM files like that would be to hit
>the following keys:
>d, e, l, , , "shift-8" (*), "miss the keyboard", "miss the keyboard", "miss
>the keyboard", "miss the keyboard", ., c, o, m
>which will be "del *.com"
>The chances of that happening are very slim, and this is in anyway diffrent
>from the dd bug since the program can't know that this wasn't something the
>user wanted - no (or very few anyway - they should use some other program,
>"cmosdestroy" or whatever) users want their CMOS destroyed.
>
>>At some time, all of us have deleted the wrong file or
>>formatted the wrong disk. Format, del, deltree and debug
>>are like loaded guns -- you need to be very careful how
>>you use them.
>
>Sure we've all done it - but due to ourselves not due to a malfunctioning
>program (except Scandisk then but I have complained about that one before).
>undelete, unformat and a backup will fix those three.
>
>>The incident which gave arise to this thread involved
>>dd (a low-level Linux command, similar in destructive
>>potential to the DOS debug command). Tell me, Bernie,
>>what would you say if a DOS newbie mangled debug and
>>crashed his CMOS ?
>
>If it was due to an error in Debug then Debug is incorrect, but if it was
>due to an error that the program couldn't be able to spot then it's the
>users fault.
>
>
>
