1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
# The Design of GCLI
## Design Goals
GCLI should be:
- primarily for technical users.
- as fast as a traditional CLI. It should be possible to put your head down,
and look at the keyboard and use GCLI 'blind' at full speed without making
mistakes.
- principled about the way it encourages people to build commands. There is
benefit from unifying the underlying concepts.
- automatically helpful.
GCLI should not attempt to:
- convert existing GUI users to a CLI.
- use natural language input. The closest we should get to natural language is
thinking of commands as ```verb noun --adjective```.
- gain a touch based interface. Whilst it's possible (even probable) that touch
can provide further benefits to command line users, that can wait while we
catch up with 1985.
- slavishly follow the syntax of existing commands, predictability is more
important.
- be a programming language. Shell scripts are mini programming languages but
we have JavaScript sat just next door. It's better to integrate than compete.
## Design Challenges
What has changed since 1970 that might cause us to make changes to the design
of the command line?
### Connection limitations
Unix pre-dates the Internet and treats almost everything as a file. Since the
Internet it could be more useful to use URIs as ways to identify sources of data.
### Memory limitations
Modern computers have something like 6 orders of magnitude more memory than the
PDP-7 on which Unix was developed. Innovations like stdin/stdout and pipes are
ways to connect systems without long-term storage of the results. The ability
to store results for some time (potentially in more than one format)
significantly reduces the need for these concepts. We should make the results
of past commands addressable for re-use at a later time.
There are a number of possible policies for eviction of items from the history.
We should investigate options other than a simple stack.
### Multi-tasking limitations
Multi-tasking was a problem in 1970; the problem was getting a computer to do
many jobs on 1 core. Today the problem is getting a computer to do one job on
many cores. However we're stuck with this legacy in 2 ways. Firstly that the
default is to force everything to wait until the previous job is finished, but
more importantly that output from parallel jobs frequently collides
$ find / -ctime 5d -print &
$ find / -uid 0 -print &
// good luck working out what came from where
$ tail -f logfile.txt &
$ vi main.c
// have a nice time editing that file
GCLI should allow commands to be asynchronous and will provide UI elements to
inform the user of job completion. It will also keep asynchronous command
output contained within it's own display area.
### Output limitations
The PDP-7 had a teletype. There is something like 4 orders of magnitude more
information that can be displayed on a modern display than a 80x24 character
based console. We can use this flexibility to provide better help to the user
in entering their command.
The additional display richness can also allow interaction with result output.
Command output can include links to follow-up commands, and even ask for
additional input. (e.g. "your search returned zero results do you want to try
again with a different search string")
There is no reason why output must be static. For example, it could be
informative to see the results of an "ls" command alter given changes made by
subsequent commands. (It should be noted that there are times when historical
information is important too)
### Integration limitations
In 1970, command execution meant retrieving a program from storage, and running
it. This required minimal interaction between the command line processor and
the program being run, and was good for resource constrained systems.
This lack of interaction resulted in the processing of command line arguments
being done everywhere, when the task was better suited to command line.
We should provide metadata about the commands being run, to allow the command
line to process, interpret and provide help on the input.
|
