Currently, in the event bash or something below it crashes, that
session's command history is lost.
It would be nice if bash saved it somewhere periodically, it doesn't
have to be too often, let's say on every second command.
That way, history could be restored from the "backup" file when the
shell
cript exits
successfully.
Does this ring any bells to anyone?
Is there any other information that would be useful to help me debug
this
further?
Thanks,
Peter.
script. I settled on 'inn' being next fastest to type.
Peter
to
those who talk to him, and ask him, what is the effort level, to
support a truly useful error message, for the 2nd word, and if they
would code the same for the word "in".
That's one man's opinion. He is not changing it.
Peter
P.S. Volunteer time is the most precious comm
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
e damned SHELL SCRIPT.
>
> How much more "non-ephemeral" can it get?
Both herestring and heredoc often contain variables, or some other
process substitution, for them to be completely literal is a less
interesting case for this issue.
Peter
On 07/14/2018 09:38 PM, Ricky Tigg wrote:
> $ man 1 bash_builtins
The variable is BASH_BUILTINS but the man page is bash-builtins
(underscore vs. dash).
Peter
post shows it isn't
entirely straightforward to implement in bash). But it's a useful
addition and making sense given existing syntax. So now just hoping for
someone to do a sample implementation!!
Thanks,
Peter
On 06/25/2018 12:27 AM, Robert Elz wrote:
> That's not the real issue - rather it is that a here doc is presented to the
> command beng run as a file descrptior
OK, thanks, that makes sense. In the case of a here-variable, that would
definitely be the case then.
Peter
re-strings and even here-documents are usually not
huge. I can see for memory-depleted systems this might be an issue, and
there are no definite guarantees about the eventual size that is
required, but (again, generally) this could all be done in memory. (And
how about storage-depleted systems??)
Pe
t of current syntax, and not clashing with anything existing as far
as I can see.
Peter
t;$var
foo bar
# Without the quotes, the tabs still get expanded, that should not
# happen, they should collapse into 1 space, this is a bug if true.
Peter
backwards compatibility and enhance bash in a
clean way, making things more readable where they would/could be used.
Peter
Sorry, indeed I meant: [[ -fx $file ]]
All -ge -ne -eq etc. options are binary operators, while these new ones
wpuld be unary, so I think the parsing would be unequivocal.
Peter
On 08/21/2017 04:20 AM, L A Walsh wrote:
PePa wrote:
In that case, would not [[ =fx $file ]] be more workable and
Assuming the input is hexadecimal, a function like this would format
each line as intended:
formatline() { printf "%010X \n";}
Then a line like this would give the intended result:
while read -r; do fl $REPLY; done
Hi all,
How can I starndarzied string column to have the same column leng
oo much. I
never thought you were thinking in this direction. I hope other people
will chime in about this approach.
Peter
On 14/06/2560 03:52, Chet Ramey wrote:
> You mean command substitution cutting off the input it reads at the
> occurrence of a NUL?
What I am really after is a shell option for command substitution not
discarding trailing newlines.
Peter
ade to work. (I still have to 'convert' the array to a normal
variable in the next step...). Would a shell option for command
substitution using NUL be a desirable feature to bash users??
Peter
might be useful.
It might be more desirable to change it to a newline instead of dropping
it? (Or both, with different flags??)
And how about a shell option to not omit trailing newlines in command
substitutions?? I find that very undesirable and unnecessary behaviour.
Peter
On 09/06/2560 05:26, Eduardo Bustamante wrote:
> What's wrong with:
>
> IFS= read -rd '' foo < "$file"
I think that's the winner!
On 09/06/2560 03:44, Geir Hauge wrote:
> Greg already pointed out that this doesn't work.
>
> You can pick one of these instead:
>
> mapfile < "$file"; IFS= foo="${MAPFILE[*]}"; unset -v IFS
>
> or
>
> mapfile < "$file"; printf -v foo %s "${MAPFILE[@]}"
>
Yes, thanks.
The second one lo
ems to be faster, but it probably has other disadvantages...
Peter
see from Eduardo's quick patch, doesn't involve a big overhead in
added complexity.
(Advocating because of living now in a country with a different script.)
Peter
ation needs to be added to bash.
Peter
for the elucidation. Sorry, my terminology was off. I meant to
say, same glyphs, different encodings/locale. A TIS-620 encoded script
works in UTF-8, like you said above.
Peter
in function names, if I write a
script in one encoding, and run it in an environment in the other
encoding, it still runs correctly, but it won't render correctly. (I
guess this depends whether the editor recognizes different encodings,
like Geany does render it correctly, but I don't know of a console
editor that does that.)
Peter
On 05/06/2560 15:52, George wrote:
> there's not a reliable mechanism in place to run a script in a locale
> whose character encoding doesn't match that of the script
>From my experience running such scripts is no problem, but correct
rendering it might depend on the client/editor.
en be
>>> READABLE
>>
>> What display/OS do you have that you can't run UTF-8 on?
So it's his mail client: reading unicode source in their old mail client
is going to be problematic for some people...
Peter
back with the same message. Strace in this case will say "Can't
stat", not "exec: No such file or directory"
Peter
On 06/05/2560 07:59, Eduardo Bustamante wrote:
> On Fri, May 5, 2017 at 7:44 PM, Peter Passchier wrote:
> [...]
>> The output from bash
the
error message be more descriptive of what's the actual problem?
Peter
On 05/05/2560 20:01, Eduardo Bustamante wrote:
> On Thu, May 4, 2017 at 10:57 PM, Peter Passchier wrote:
> [...]
>> $ file /home/pp/bin/caddy
>> /home/pp/bin/caddy: ELF 64-bit LSB executable,
me/pp/bin/caddy
/home/pp/bin/caddy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib/amd64/ld.so.1, not stripped
$ ls -AFl /home/pp/bin/caddy
-rwxr-xr-x 1 pp pp 16229894 2017-05-05 10:30 /home/pp/bin/caddy*
I would think that is a strange response...
Peter
On 22/03/2560 01:32, Martijn Dekker wrote:
> A workaround for the original poster's problem could be:
>
> (unset -f jobs; unalias jobs; eval 'jobs -l') | wc
'unset -f jobs' is not guaranteed to unset jobs, it might set jobs to a
function definition in an earlier scope..!
to expect) in a dynamically scoped language as a
matter of principle?? If unset works like you would want/expect it, it
would also discard all values of all higher scopes. Would it not be
better to set IFS to the value desired (whatever default splitting
behaviour you need)??
--
Peter
Depending on your use case, you could do something like:
$ echo $'\u2010'n
-n
On 06/02/2560 13:37, Clark Wang wrote:
> On Mon, Feb 6, 2017 at 12:15 PM, Jyoti B Tenginakai
> mailto:jyoti@in.ibm.com>> wrote:
>
> Thanks you all,
>
> Again I see that this printf we can use. But there are
I guess they are not equivalent, piping into bash opens a subshell, and
sourcing doesn't; these act differently:
echo exit |bash
echo exit >r; source r
Hope I've gotten it right now. Thanks,
Peter
On 31/12/2559 11:20, Peter & Kelly Passchier wrote:
> Thanks Dennis and
echo $r; echo -e 'r=bc\necho $r' |bash
Thanks again,
Peter
On 31/12/2559 11:07, Grisha Levit wrote:
> On Fri, Dec 30, 2016 at 11:03 PM, PePa <mailto:peterke...@passchier.net>> wrote:
>
> r=23; echo $r; echo -e "r=bc\necho $r" |bash
>
> You
Is this a bug? These both output "q=1"
q=1
[[ ((q==1)) ]] && echo q=1
q=0
[[ ((q==1)) ]] && echo q=1
WHich docs?
If I do "help test" it states: "All file operators except -h and -L are
acting on the target of a symbolic link, not on the symlink itself, if
FILE is a symbolic link."
Peter
On 14/10/2559 02:00, Łukasz Grabowski wrote:
> Configuration Information [Automati
So, for context, I'm aware that this is by no means a normal or reasonable use
case. I'm the maintainer of pseudo, a program used by build systems to allow
developers to create filesystems with permissions, modes, and device nodes,
without actually requiring root privileges. (Similar to fakeroot.)
actually be good if
the default behaviour of glibc was to report a regex compilation error
in that case, or maybe even better, print a warning like "\d: unknown
special character, treating as literal".
Of course, POSIX doesn't specify either \s or \d, just the
[:space:] and [:digi
On Thu, Nov 28, 2013 at 12:40:34PM -0500, Chet Ramey wrote:
> On 11/28/13, 7:23 AM, Peter Cordes wrote:
> > I submitted this on savannah a couple days ago:
> > https://savannah.gnu.org/support/?108450
> >
> > As I said there, the warning message for bash re-using a
something weird that wasn't my fault.
Oh, also, the online bug-bash archive has a bad habbit of replacing
code with address@hidden. There was a whole thread about setting
PS1=whatever that is now a complete mystery to non-subscribers!
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter
e only odd thing I found while playing around
with this is that printf %c only prints the first byte of the UTF-8
representation of a multi-byte character. (POSIX says to be
"extremely cautious" about using %c with wide characters, apparently
for good reason.)
--
#define X(x,y) x##y
Pete
OK, that makes sense. Sorry for being confused. I thought that by this
level, ^D and EOF are equivalent. I should be able to check to see if
the character returned is ^D, then act accordingly.
Peter
On 07/27/2013 03:10 PM, Chet Ramey wrote:
On 7/27/13 1:32 PM, Andreas Schwab wrote:
Chris
I was using ^D as an EOF. I guess I should have tried it in other ways.
Is ^D not the same as EOF? Sorry if that is a noob question. I was able
to reproduce all of your outputs. I am using xterm as my terminal
emulator, if that matters.
Peter
On 07/27/2013 10:35 AM, Chris Down wrote:
Hello
ions for a work-around
if it can't?
Peter Olson
read only. What the hell
were you thinking? Why not use the EDITOR variable? That's what it's
for! Not everyone knows how to use every editor.
So here is an email instead, with copy & paste from what I wrote in that
thing before getting annoyed and using "kill -9".
F
one works in version 3
true
===
4.1.10(4)-release:
-> [[ a =~ a\|b ]] && echo true # ... but not in version 4
-> [[ a =~ a|b ]] && echo true
true
Do I really need to check BASH_VERSION first?
Thanks & regards,
Peter
rk the way I intend. This, or some later version, will be part
> of the next bash release. I am soliciting feedback on this iteration.
the users here are happy with this patch, looking forward to see it
in the next release.
Peter
On Mon, 18 Apr 2011 20:12:24 -0400, Chet Ramey wrote:
On 4/14/11 6:19 PM, Peter Toft wrote:
I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try
to move
to a subdirectory of another directory (e.g. $HOME), where the
tab-expand
works poorly;
Assume $HOME=/home/pto
You should
On Fri, 15 Apr 2011 15:07:16 +0800, Clark J. Wang wrote:
On Fri, Apr 15, 2011 at 6:19 AM, Peter Toft wrote:
Hi all
I have been using tcsh for a long time on Red Hat Linux boxes, and
bash on other UNIX-boxes. One thing I really love with tcsh is the
way
I can swiftly operate using the to do
I like where the
infamous space is replaced by a slash when doing "cd ... "?
Best
--
Peter Toft, PhD
http://petertoft.dk
part about "strictly textual" and "performed
before all other expansions" in the manual, but I didn't realize all the
consequences. This means that my quotes get interpreted *after* the
brace expansion is done, right? As a result, a call like
echo "$(echo "{1..3}')'
ends up as
echo "$(echo "1')' "$(echo "2')' "$(echo "3')'
and that surely won't work.
This makes a lot more sense now.
Thanks again,
Peter
quot;)"
{1..3}
?
I saw this happening on every version of Bash I could find -- ranging
from Bash 4 in current Arch Linux to some old Bash 3 of msysgit[1] on
Windows. Tried it on the last two or three versions of Ubuntu. And so
on. To be honest, this almost convinces that I really missed some
o fix libtool to not cause this problem too, of course.
Thanks,
Peter
ing somewhere I
could easily find this out.
cheers,
- Peter
--
PRAGUE: Home of the world's finest beer -- http://prague.tv/toys/beer/
on."
Better way to check if shell is login is:
$ shopt | grep login_shell
login_shell on
--
Peter.
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='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
ns \W or \w and
directory name is multibyte with the above mentioned conditions.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
(at least with
some man systems).
regards
Peter Breitenlohner <[EMAIL PROTECTED]>A VPATH build fails to install bash.info (in Versions 3.x this
file is in the build tree, not in the source tree!).
The patch (inspired by automake) covers both possibilities.
diff -u
On Пнд, 2007-03-26 at 17:35 +0200, Andreas Schwab wrote:
> Peter Volkov <[EMAIL PROTECTED]> writes:
> > Steps to reproduce:
> > PS1="\e[36m[\e[34m\u\e[0m \e[32m\w\e[36m] \\$\e[0m "
>
> This is broken. You need to bracket escape sequences with \[ \].
E
z
Bash 3.1.* works correctly.
==
is reproducible with patch Chet provided in thread "bash-3.2 regression:
broken colour prompt". So i think this is another bug. Thank you in
advance.
--
Peter.
signature.asc
Description: This is a
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2
-mtune=pentium-m -fomit-frame-pointer -mcpu=pentium-m -pipe
uname output: Linux camobap 2.6.19-gentoo-r5-suspend2 #7 PREEMPT Sun Feb
11 19:07:33 MSK 2007 i686 Intel(R) Pentium(R) M processor 1700MHz
GenuineIntel GNU/Linux
Machine Type: i686-pc-li
On Сбт, 2007-02-24 at 09:37 +0100, Andreas Schwab wrote:
> Volkov Peter <[EMAIL PROTECTED]> writes:
> > I've checked this behavior and in xterm everything works. Thus seems
> > that this is konsole bug and bash works as it should.
>
> Except that is also fails in x
ole bug and bash works as it should.
Thank you for your answer.
Peter.
signature.asc
Description: This is a digitally signed message part
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
ONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/home/peter/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib
-g -O2
uname output: Linux camobap 2.6.19-gentoo-r5-suspend2 #7 PREEMPT Sun Feb
11 19:07:3
exit
>exit
>exit
>logout
You can turn cleartool into a function that exits the shell after
running the real cleartool.
cleartool() { command cleartool "$@"; exit; }
Works in both shells.
--
Peter Stephenson <[EMAIL PROTECTED]> Software Engin
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: i686-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/loc
he arguments to [[ don't undergo any of the expansions that
> require quoting to protect them, there's no reason for =~ to act
> differently than the other operators that do pattern matching.
Never noticed that. This is really interesting.
Thank you all for your answers,
Peter
uot;string" =~ "[a-z]" ]] && echo something
something
echo me something. IIUC the regular expression [a-z] matches any single
letter, so how string "string" matches one letter?
Seems that I missed the point, or did I encounter bug?
Thank you for any help,
Peter.
signatur
profile and ~/.bashrc
under root work's everything ok
all users are allowed to read /etc/profile
and in /etc/passwd is /bin/bash for all user .. included root
do you have any idea how solve this problem?
thanks
peter guspan
Rep
On Чтв, 2005-08-25 at 08:46 -0600, Bob Proulx wrote:
> Peter Volkov Alexandrovich wrote:
> > P.S. I'm not subscribed to the list, so please CC me.
>
> > I need to run ssh in background just to forward ports. But anytime I put
> > it into background process state be
ap signals, but
I can not trap STOP signal. What else can I do?
I'm using:
[EMAIL PROTECTED] ~ $ bash --version
GNU bash, version 3.00.16(1)-release (i686-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
Thank you for your time,
Peter.
P.S. I'm not subscribed to
und weisst es nicht einmal:
http://www.heise.de/newsticker/meldung/58003
http://www.heise.de/newsticker/meldung/59304
http://www.heise.de/newsticker/meldung/58311
http://www.heise.de/newsticker/meldung/58351
___
Bug-bash mailing list
Bug-bash@gnu.or
74 matches
Mail list logo
