> 1. Bash re-starts history each time it goes into a subshell.
> I think it would be much more reasonable to keep a uniform history
> for a given login session, even if, for instance, you started the
> "script" command to keep track of what you are doing. Or at least a flag
> that allowed a single history, even when you run multiple windows. Is
there any
> documentation or explanation of standards for this, or why one way was
> chosen over another?
When the paradigm under which Bash was architected was established, doing
something like a single inter-process history would have been considered
totally insane. The history is kept in memory with the bash process. A
system-wide history might be cute (though personally I would need to have
a brain transplant before it'd occur to me to enable that), but it would
be WAY beyond the "keep it simple" functionality of a traditional shell.
You could always write a shell function that dumps the history so that
your subshell can load it up.
> 2. In the emacs editing mode for command lines, in bash, the
> tab character is used for command completion, making it VERY difficult
> to put tabs into text lines (you have to use "^V" before each tab
> character. The problem could be greatly helped by just accepting
> back-slash or single quote escape characters, to be consistent with other
> special characters.
In zsh at least I think all the key bindings are configurable. And
not to trivialize your question, but why would you want to put tabs in
command lines? I'm trying real hard to remember the last time I wanted
to do that ...
Confusing the quoting of shell syntax with quoting of "hot" keys would be
a Really Bad Thing, in my opinion. The thing that's doing history editing
is clearly a separate layer from the parser that eats backslashes and
single quotes. Effectively, you'd be turning those characters into hot
keys themselves, so you'd need a way to say "no, I'm not typing backslash
because I want to quote an upcoming tab character, I'm doing it to quote
a space character in a filename". That'd be really weird.
> 3. In the redhat distribution of Linux, there is something
> wrong with the prompt variable, PS1, so that it has to be set in
> /etc/bashrc. This means a user has to know enough to set it in their
local
> bashrc, rather than .bash_profile. Anyone know why this is, and what the
> problem Redhat is solving is?
% bash
[m5@nirvana PMA]$ PS1='foo foo '
foo foo date
Fri Nov 17 17:29:47 CST 2000
foo foo exit
exit
I don't have a problem with PS1, as you can see. I suspect that what's
happening is that PS1 is set in /etc/bashrc, and that that is run after
.bash_profile. Why not just take it out of /etc/bashrc?
> 4. The most annoying problem (and I'm pretty sure this in
> *not* local to just bash, and may be true in every shell for all I know)
> has to do with pipes. WHY ARE BOGUS PIPES ALLOWED without some indication
of
> of a syntax error???
Because it's not a syntax error.
> That is, if someone says:
> sort file > newfile | cat newfile
> bash (and ksh, I think) accepts this without question.
That's because it's syntactically OK. You're telling bash (scanning left to
right) to reopen stdout with "newfile", and then to reopen it again to the
write end of the pipe. (Actually I guess the pipe happens first, and the
right-hand side will fork off the left-hand side before the left-hand side
re-opens stdout.)
That's a little bit of sophistry, but the shell wasn't designed to keep
people from typing in clearly meaningless commands.
> It can lead to a very subtle error for new users,
That doesn't look too subtle to me. What could a person possibly imagine
that command line to mean?
That said, shell programming is EXTREMELY prone to wierd bugs. Therefore,
DON'T DO IT. Write your programs in Perl or C or Java or something. Shell
scripts more than (pick your small number) lines long are an indication of
demonic posession.
> Why can't the shell put out a warning message (at a
> minimum) when it sees stdin or stdout being used around a pipe. A pipe
> doesn't mean if either is not being used!
The shell is a programming language. Like a lot of programming languages,
its syntax allows the expression of semantically meaningless statements.
I personally don't want my shell spending time analyzing my statements.
I encourage anyone and everyone to expand on ideas for introductory
command line interpreters for Linux. Bash is not one of those.
Mike McNally -----> Yes, I already have a dumpling press
[EMAIL PROTECTED]
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
