Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -D
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2
-L/usr/src/packages/BUILD/bash-3.2/../readline-5.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYP
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc -I/usr/src/packages/BUILD/bash-3.2
-L/usr/src/packages/BUILD/bash-3.2/../readline-5.2
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYP
reasons I want all my
sessions to write to--and more importantly, to read from--the same
history file.
And in this the case the suggested workaround is loaded with flaws. For
example, it's quite easy to be logged in to the same filesystem multiple
times under the same tty name. (Think NFS.)
; but bash has never had such a feature, thus calling it a bug is
> specious at best. New feature, yet, bug... stretching the word.
This would be where I am glaringly guilty of bad writing, because if I
had written clearly you wouldn't have said that. I am most definitely
NOT asking for &
long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
>
--
Geoff Kuenning ge...@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
If we knew what we were doing, it wouldn't be research, would it?
-- Albert Einstein
uffer would be in-memory
at that point, since the processes can exit much faster than the buffer
could be written to disk. So I don't think that's it.
> (multi-threaded ops on real multiple execution units do the darnest things).
Ain't that the truth!
--
Geoff Kuenning g
system crash as you mentioned,
> so I can't see how it would cause the symptom you are seeing, but it's only
> seen in crashes in more mature file systems. Can you reproduce it on another
> file system like xfs?
Good question. Unfortunately that's not a practical experi
ould be OK unless a second SIGHUP arrives. (Does
bash re-enable signals when the handler gets called? Seems unlikely,
but...)
--
Geoff Kuenning ge...@cs.hmc.edu http://www.cs.hmc.edu/~geoff/
The "M" in XML stands for _markup_. If you don't have anything
outside the angle brackets, you probably shouldn't be using XML.
So having done some more playing around with this, I've found that when
bash is configured and compiled with '--enable-strict-posix-default',
this doesn't occur. I see this is documented in the change log for
4.3alpha, as:
k. When compiled for strict Posix conformance, history expansion is
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='p
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='p
lls. For precisely that reason, my
startup files are careful to avoid resetting CDPATH, so that if I want
to change it and then invoke an interactive subshell I won't have to
change it a second time.
In general, it's a bad idea to assume that one's own usage patterns
match those of all ot
ut the security implications of this
one, because I don't know everything it changes.
Superficially, it seems OK, but somebody more
knowledgeable about all its effects should spend some
time thinking about how to crack a script by
tes and then removes
temp files to fail to remove them due to globbing. Then I might look
for situations where I could cause a denial of service by causing lock
files to not get removed.
--
Geoff Kuenning [EMAIL PROTECTED] http://www.cs.hmc.edu/~geoff/
The most exciting phrase to hear i
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='p
Thanks very much. This does beautifully.
Geoff Odhner
Chet Ramey <[EMAIL PROTECTED]> wrote on 05/06/2005 09:35:18 PM:
> Geoff Odhner wrote:
> > Configuration Information [Automatically generated, do not change]:
> > Machine: i686
> > OS: linux-gnu
> > Com
the wildcard is not expanded.
Other comments: I've observed similar behavior with tab expansion
and complex pathnames that contain "surprising" characters such as
parentheses, spaces, and nonprinting characters, but I'm not sure
whether it's related.
--
Geoff Kuenning
pass judgment on the weird things you do even though I
don't understand them", argues for being able to handle any
arbitrary sequence of bytes, at least on Linux. That's one of the
things that makes the Unix paradigm so powerful. So I appreciate
your willingness to fix this.
On 9/
S=betty:pebbles:\$RUBBLES"
Hopefully, you can use this information to see if there is a problem.
Cheers,
Geoff
test_aliases
Description: Binary data
o the behaviour I first experienced (i.e.
Rubbles=barney after running assemble_fam1 then assemble_fam2), then I put
the default COMMAND_PROMPT back:
PROMPT_COMMAND='printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}"
"${PWD/#$HOME/~}"'
Does this w
Aha! That's it. Case closed, I think.
Thanks,
Geoff
On 2 March 2017 at 05:07, Reuti wrote:
>
> > Am 01.03.2017 um 16:53 schrieb Grisha Levit :
> >
> > On Mar 1, 2017 1:04 AM, "Geoff Hull" wrote:
> > If I want to go back to the behaviour I
22 matches
Mail list logo
