Re: Guishell project looking for collaborators

jimrandomh@xxxxxxxxx wrote:
On Nov 17, 7:48 am, Frank Mertens <fr...@xxxxxxxxxxx> wrote:
You really not even know to use a shell, but want to write one.

And this is the part where you're obviously trolling.

For instance 'man apropos' could have told you to write 'apropos -s 1
copy'. Take a look at 'man man', if you want to learn about the section
meanings.

We must have different implementations of apropos, because mine gives
"-s: unknown option", and doesn't mention it (or any other option that
would narrow the search by manpage section) in its man page. It
doesn't matter though, because I was giving a use-case in which the
user wouldn'tve known what section to look in anyways.


And what's the point of supporting illiterate users?.
'man man' brings a list of sections in the most simple language into
your eyes. And 'man apropos' would tell you your '-s' option.
Ok, I must be fair. You need to know 'grep'.

'apropos|grep \(1\)'

I really would love to see context menus or a wizard to get newbies
started with the basics (cat, grep, less, tee, find, ...).
The real power comes from combining these tools. The wise Imhotep would
have drawn an icon for each tool, but how to fit that onto a keyboard?
Maybe dragging and dropping tool icons, connecting pipes with a mouse?
Until recently people would have assumed hitting 3 to 5 keystrokes
is more user-friendly. But it may be different for learning to use
a mouse to place commands. Or will the keyboard be replaced by a more
flexible touch board? You have seen that touch panels the MI6 is using
in the lasted James Bond movie?

Someone could also overload the $PAGER to put the manuals in a separate
window. The $EDITOR is probably another thing you need to get rid
of to not confuse a newbie. I remember myself being lost first time
in a 'vi'. Anything else in that line?

If it should be more limiting (to not shock a Windows migrant),
maybe busybox is the way to go? Though integrating everything into
a single shell interpreter is stupid from the security perspective.
Busybox works nicely around that by spawning a new instance of
itself for each command executed.

Also do you know, that you invited others to join into a UNIX shell
project, by sending a message from a Windows machine?

I mentioned a Cygwin port in my original post, from which anyone could
infer that I must have at least one Windows box around. I'm not sure
what your point is.

For instance bash runs fine everywhere because it makes very limited
use of job control only. Windows has no support for pseudo terminals,
sessions or even very basic process forking. You can not even spawn
a worker process with an empty environment (via CreateProcess).
Cygwin does a great job in hiding lots of these system deficits,
but it won't ever provide you more than a completely outdated
and utterly slow POSIX layer.
So, I naturally hate to see people spending money and wasting their
time on legacy systems (me included).

And you get it, that you are part of the problem of having
only very limited shells? Yet you are accusing current shells
of being "hobbled by anachronisms" in your concept.txt.
That I mean with spitting on other people's shoes.

And so that everybody gets what I'm talking about, your concept.txt:

===============================

guish - Fixing the Unix command line

The Unix command line is hobbled by anachronisms and long-standing
issues which
date back to a time when computers often sent their output to printers
rather
than monitors, memory was scarce and the mouse hadn't been invented yet.
Despite its quirks, it is used almost universally by programmers and system
administrators. Because the Unix shell is so universal, any issues which
could be addressed by modifying only one piece of the system have
already been
addressed; the issues which remain all stem from a few architectural
problems.
In fact, there are bugs which can't be fixed and important features which
cannot be implemented without fundamentally changing the architecture of the
Unix command line. This project aims to do just that.

Bugs Which Can't be Fixed

Output mixing: All programs run from a shell share an output pty, so their
outputs mix together. If several programs are writing at the same time
(usually a backgrounded program and a foreground program), there is no
way to
tell which output belongs to which program; in the worst case, it alternates
with each character, making the output totally illegible. (I have seen make
-j2 do exactly that to compiler errors/warnings.)

Final newline: If the last thing a program outputs is not a newline, the
next
prompt will not display correctly.

Terminal resizing: Each terminal has a controlling process, which receives
both keyboard input and signals from that terminal. The controlling
process is
either the shell or a program launched from it, but can't be both at the
same
time. This causes a problem with resizing terminals. When you resize a
terminal window, it sends SIGWINCH to the terminal's controlling process to
notify it that the window's size has changed. If the controlling process
is a
text editor or pager, then the shell is never notified, so the shell and any
programs launched later continue using the terminal's old size, which
makes a
mess of things. (bash has a workaround, disabled by default: you can make it
to poll the window's size whenever a program finishes with shopt -s
checkwinsize).[1]

....
=============================== [snip]

I don't need to post the rest of it. Its 99% technical nonsense.
For instance lets take a read into 'man tty_ioctl'.
The manual states clearly:

"When the window size changes, a SIGWINCH signal is sent to the
foreground process group."

And not just to one process or another!
And why to hell should bash receive SIGWINCH, maybe even SIGTERM when
it's in the background? It is not generating any output at this point,
does it?
When a shell gets back into the foreground by setting its group id
to the group id of the terminal it may also update $COLUMNS, $ROWS
by ioctl TIOCGWINSZ. Why you call that "polling"? Of course its an
option you can switch off in case you are using a physical terminal,
which never changes size.

Coincidently I also know that your NT5.1 has no signals support.
It has process groups but no signals. Take a read on msdn,
they dubbed their version of kill(2) "TerminateProcess".
Certainly therefore you need to poll to keep track of the window size.

So, Jim, what shall I think what you are all about?

Let's compile a list, because we both ain't illiterate.

Small list of what's wrong with the concept:
- SIGWINCH you got completely wrong.
Maybe Windows or putty has no signals?
- Contradicting security claims, because only simple systems go secure.
But we need to embed a browser?
Again reading manuals would be helpful.
(Maybe mozilla -new-tab URL?)
- False claims about missing features, like limited scrollback.
For instance the xterm clone on OSX even defaults to endless logging.
In my KDE4 konsole you can enable it manually.
That particular 'konsole' has actually already lots of features,
which your project is going to create. (And consider 'konsole'
and other vte as moving targets ;+)
- Nobody would use a terminal that frequently shows undefined
states. Another example of misunderstanding very basic concepts.
So your terminal frequently goes bust showing undefined behavior?
And you not even being able to reset it?
I worked on terabytes-large binary files for years on lots of
different vte and I never got into this situation.
Especially because of security breaches nobody would want to
use such a terminal you are describing.
'putty' is no serious video terminal emulation!
- Not listing of any reference to any existing approach of improving
the terminal protocol. There are some in 'comp.terminals'.
For instance take a look at http://kbterm.sourceforge.net/.
- Fantasy claims about how to use pseudo terminals to redirect any
process output. What about the children of the children of your
shell process?
- False claims about wrong or broken buffering mode.
Again see 'man termios' (e.g. on OSX) to get it right.
The manuals states you all the information to configure your pty.
If you output something in canonical mode, why would you expect it to
appear immediately?
For instance take a look at http://www.happypenguin.org/show?bastet
to see how to freely control cursor movement and text output.

It took time reading your 'doc' folder and but I also want to
leave some comments on the source.
The published code of yours has still no observable working features,
beyond having copied putty code. That's not a good foundation
to start a project on improving the command line. And I fear guishell
will just betray users about the realms of working in an UNIX shell,
in the way it is currently targeted.

The only reason I have taken such a deep dive into your work is that
I also feel the terminal control sequences need reform.
If I look at the current state in 'man console_codes' (Linux),
I really get headaches. Regarding your protocol spec. I glimpsed it is
going to be also slightly complex. Have you considered, that your
terminal never should enter any state during its operation from which
the user can't escape? I mean the stream of control sequences can
be interrupted between any two bytes, for instance if the generating
process receives a signal.

Advertising the command line to people that do not appreciate reading
or writing is an interesting point. Indeed, revolutionizing a writing
systems can have a gigantic impact. Just look at the pyramids!
(Now I was trolling again;)

I will try get my part more polite the next time,

--
Frank
.

Relevant Pages

  • Re: Standard input
    ... how it turned out on Windows ... ... hardware terminals and so the concept is well developed in ... lives on as "pseudo-terminals". ... connected to the shell ...
    (comp.lang.fortran)
  • Re: is there a package that will remotely run a unix command from a windows box?
    ... It also has a better shell than the windows CLI. ... > a bash nearly identical to the linux version. ... terminals that were more than just one CLI (a shell being extra features ...
    (Fedora)
  • RE: BSD Questions.
    ... >>>Windows XP is the best that you can do for the ... >innovation of consultants and network staff than ... >With laptops being so prevalent now; ... dumb terminals and terminal-serving into a Microsoft ...
    (freebsd-questions)
  • Re: HELP! Onan Emerald III No AC
    ... While it was running I did check the terminals on the back of the electric ... have welded together (K2 is energized by the battery charge windings, ... control board does, ... jumper lead from the battery terminal at the solenoid to the control box ...
    (rec.outdoors.rv-travel)
  • Re: Great SWT Program
    ... terminals though. ... If you want them in separate windows (rather than in separate terminal ... Whereas over here I can switch between several ... editing sessions for more than one *type* of thing going concurrently ...
    (comp.lang.java.programmer)