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.
