D on Slashdot

[Kagamin via Digitalmars-d]

On Thursday, 22 January 2015 at 16:13:31 UTC, ketmar wrote:
>> > somehow i can't close cmd.exe by hitting ctrl+c. don't 
>> > console programs
>> > know what ctrl+c is for?
>> Well, maybe because it's a shell, not a utility?
> shell is a console utility.

Hmm... shell is a user interface providing access to the system 
and utilities. It's different from user utilities in that it's a 
system component, making the whole thing usable at all. It 
shouldn't terminate conventionally, because then the user remains 
without access to the system, that's why console shell doesn't 
terminate on ctrl-c and GUI shell doesn't terminate on alt-f4. 
But a text editor should definitely terminate in a conventional 
manner.

> strangely, ctrl+c is not working in FAR too. it's not a shell. 
> it's obvious console.

Maybe they just don't give a shit about it? Or they see it as a 
shell. Truth be told, FAR has a quit button at the bottom.

>> It fills in file names which match what you typed, this is 
>> exactly what autocompletion is for. What's so difficult to 
>> understand there?
> it's difficult to understand how it does thelepaty. from my 
> expiriense,
> it's thelepaty is completely wrong each time. and with putting 
> the
> whole filename i don't even know where was ambiguty (and if it 
> was at
> all). so "afjgjoe" means, that this is the only match, or there 
> are
> more matches? nobody knows, until he hits tab again. and then 
> he lost
> his "afjgjoe" and have to either tabbing furiously to get it 
> back, or
> type it manually. perfectly unusable "autocompletion".

Well, that's your implementation. In fact shift-tab returns the 
previous entry. It's a popular reversal modifier, e.g. in a 
tabbed browser ctrl-t opens a new tab and ctrl-shift-t opens 
previously closed tab, in a text editor ctrl-z is "undo" and 
ctrl-shift-z is "redo".

>> Literal means just a value typed in directly instead of being 
>> taken from a variable, that's all to it.
> good luck redefining what the shell does from the times when 
> "windows" was a term from housebuilding.

The term has nothing to do with windows, it's from theory of 
programming languages, such things usually tend to be quite old, 
maybe even older than unix. I think, my understanding corresponds 
to the established one, and bash docs use it too.
Some reading:
http://en.wikipedia.org/wiki/Literal_%28computer_programming%29 - 
about literals in general.
http://en.wikipedia.org/wiki/String_literal - more about string 
literals specifically; the "Delimiter collision" section 
explains, why string literals need escaping.
http://www.gavilan.edu/csis/languages/literals.html - an 
extensive article about literals; interestingly, Hollerith 
strings don't suffer from delimiter collision and consequently 
don't need escaping.

> i was trying to explain you what's going on. ah, ok, good luck 
> arguing
> with machine code, telling it that it must do not what it do.

Well, it's not really needed. User only types the first 
characters without quotes, no need for them really; then quotes 
are added by the autocompletion algorithm, if needed.

>> As I explained, the file can start with a difficult to type 
>> character, requiring to type it is unnecessarily daunting.
> and you know what? if you hit tab twice on empty line in bash, 
> you'll
> eventually see something like this:
>
>   Display all 4788 possibilities? (y or n)
>
> good luck browsing thru that.

On windows you can choose to iterate through some first of them 
or try something else. There are extreme cases, but they are, 
well, extreme. User folders are likely to have small number of 
files.