> > 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.
There is a command to force history in and out:
history -w writes to the current history file
history -r reads the "new" parts of the file
I use this to get around the problem, in a "newscript" function (it didn't
work when I just made it a command; it didn't read the history at the right
point).
Just to show that I'm not totally crazy, just a ksh user in a different
context, I quote from "The Kornshell", by Morris Bolsky and David Korn:
page 77: "Separate invocations of ksh share the history file between all
instances that specify the same name and have appropriate permission.
Commands typed from one invocation are accessible by all the interactive
instances of ksh that are running concurrently and sharing the same history
file. On a terminal with multiple windows, you can type a command in one
window and access it through another window"
I find it useful in general, but in the particular case of running the
script command, I find it essential!
> > 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.
You may be right that its a bad thing, but I'd like to be able to do
real simple listings at the terminal:
ls -l | tr -s ' ' | cut -f3,9 | sed 's/ /<tab><tab>/g | cat heading -
makes a quick, simple list of file ownership; I could do it better in
perl, but this would be much simpler, and "readable enough".
bash allows command line editing in either vi mode or emacs mode; I
believe the tab key is only enabled for command completion in emacs mode.
I haven't found a way to turn it off, or use something different. (I
don't think ksh has an equivalent line edit command.)
> > 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?
Yes, you have the problem exactly. PS1 is set in /etc/bashrc, with a
comment that says it is necessary to set it there, but no mention of why.
That's why I'm asking.
> > 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?
A beginner simply takes the "|" to work like a ";", and their limited
testing seems to show that to be correct. They are likely never to get
processes that take enough time to show the mistake, in simple testing.
Perhaps you are correct, that we should give up shell scripting and go
directly to perl!
> 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
>
>
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
