On 2016-06-01 at 10:40 -0400, Greg Wooledge wrote:
> On Wed, Jun 01, 2016 at 03:33:23PM +0200, Christian wrote:
> > sh and zsh both return the expected x=~
> >
> > sh -c "echo x=~"
> >
> > x=~
>
> imadev:~$ bash -c 'echo x=~'
> x=/net/home/wooledg
> imadev:~$ bash -posix -c 'echo x=~'
> x=~
Benno Schulenberg wrote:
> On Tue, Feb 16, 2016, at 11:19, Bob Proulx wrote:
> > [...] this is the perfect case for job control. No need for a
> > second terminal. Here is an example. Use Control-Z to stop the
> > foreground job.
>
> For that to work, it requires having 'set suspend' in your
>
* expands to all the files in the current working directory, as can be
seen with:
echo *
if you just run:
*
then you will be running the first file of them.
*But* if you have a program that allows to provide an arbitrary "*" as
the first command parameter, it would allow inserting the name of
Yuri wrote:
> On 02/03/2016 14:06, Greg Wooledge wrote:
> > Works for me.
> >
> > wooledg@wooledg:~$ PS1=$'\u2023 \w\$ '
> > ? ~$
> >
> > I just can't show it in this cross-system-X2X-with-different-
> > character-sets
> > setup. But it works for me, on Debian GNU/Linux with
> >
Chet Ramey wrote:
> The current configurable startup file options are insufficient for
> their purposes because they can be enabled or disabled by vendors,
> and these folks would rather not modify the "vendor" parts of the
> system. In some cases, with some Linux distributions, doing so voids
>
Bill Duncan wrote:
> Remember that while there are 14 patterns of years, leap years don't
> impact Friday the 13th for January/February..
>
> This isn't an exhaustive analysis, but a quick check for 300 years
> didn't show any years without a Friday 13th..
>
> ;-)
>
> $ for y in {1900..2199} ;
Hello heliogabalo
It doesn't seem your problem is really related to bash but rather with
apparmor and the other application you are running.
Hola helogabalo, me parece que tu problema no tiene relación con bash,
sino con apparmor y el programa que estás intentando ejecutar.
Greets
Dennis Williamson wrote:
> Do you mean something like:
>
> PS1='$SECONDS '
Not exactly. $SECONDS is the number of seconds since the shell was
started. I am interested in the seconds elapsed by the last command.
It is a hacky solution, but it could be done with:
> PS1=''; PROMPT_COMMAND='printf
While we are talking about new prompt escapes, I would love to be able
to put in the prompt escapes elapsed time values from the previous
command, so prefixing with time(1) could be redundant (if the intended resource
was provided as an escape).
Regards
Robert Parker wrote:
> Yet when I attempt the same in a C program, the system always writes
> 2 prompts, then waits for a read.
> Does not matter if I write(1, "..."); read(0, number, buffer); or use
> fputs("...", stdout); fgets(.
> The result is the same.
> And I have tried using readline
Mostafa Nazari wrote:
bug_part (echo TEST)
The (echo TEST) construct creates a pipe. You can view it just
printing the value that gets passed to the program:
$ echo (echo TEST)
/dev/fd/63
Now, a problem of that pipe is that the contents can only be read once.
Indeed, what would the second read
Andreas Schwab wrote:
Bob Proulx b...@proulx.com writes:
Andreas Schwab wrote:
Ángel González writes:
entering «/^ *read⤶» may be easier to type (and remember)
It won't match, though.
It matches fine for me.
How? There is no ⤶ in the output.
Andreas.
I was trying
On jue, 20-08-2015 a las 17:38 -0700, Linda Walsh wrote:
Functions are a collection of many commands. They are not a single,
simple statement. I remember using their return value in some cases.
With the change, I couldn't run a func and have it return the
value in $? (1 byte, I know) --
On Andreas Schwab wrote:
Try searching for '^ {7}read ' instead. There are commands that
aren't followed by options in the description.
entering «/^ *read⤶» may be easier to type (and remember)
On Tue, 2015-04-28 at 21:27 +0200, isabella parakiss wrote:
I'm sorry, I added a link to a pastebin in my previous message but
it's not available anymore.
Anyway, this was the content (posted by Score_Under in #bash):
I think -- should enter said directory.
I hope it's ok...
It may be
gennady.kupava wrote:
This looks like a bug:
gena@note2:~$ echo a
b | echo '!'
bash: !': event not found
^C
gena@note2:~$
Is it?
Gennady
IMHO it is. Confirmed in 4.3.30
Askar Safin wrote:
Please stop mischaracterizing the issue. It's not a bug: it's a case of
konsole's mismatched expectations. Since the mechanism it uses is not
documented, and relies on something in readline that is not documented, it
can't fairly be called a bug.
Should long text line
Doesn't seem like a bug to me. You asked your terminal emulator to clear
the screen. It did so. Now you complain that it's too clean :)
I understand how it may look confusing, but I don't think the term has
much option here. Suppose that instead of the shell, you were executing
something else
Piotr Grzybowski wrote:
Hi Chet, hi all.
based on what you say, and some comments in parse.y ;-) isn't the
below patch enough to get rid of the parser error for time;echo;
case?
diff --git a/parse.y b/parse.y
index 815db98..766f258 100644
--- a/parse.y
+++ b/parse.y
@@ -1224,6
On Andreas Grünbacher wrote:
With errexit, you get vastly different results from functions depending
on how the functions are called, for example,
foo() {
echo foo: top
false
echo foo: bottom
}
set -o errexit
# bottom of foo reached:
if foo; then
Andreas Grünbacher wrote:
Hi all,
the errexit option can be very useful in simple scripts. This option
is being ignored in many contexts like lists and conditionals though.
I understand that this is by design and that errexit cannot be
fixed to behave more reasonably. Still, this makes bash
Eric Blake wrote:
On 10/08/2014 08:52 AM, Stephane Chazelas wrote:
When bash parses code it honours the blank character class in
the current locale as token separator.
For instance, if x is a blank character in the current locale,
Such a locale is invalid per POSIX; but the invalidity
Notes Jonny wrote:
On Mon, Sep 29, 2014 at 2:04 PM, Chet Ramey chet.ra...@case.edu wrote:
On 9/29/14, 8:22 AM, Notes Jonny wrote:
Hello
I noticed hash_search() did not check if string parameter was
non-NULL. Please find attached a patch for this.
It's the caller's responsibility to
Chet Ramey wrote:
On 9/28/14, 12:31 PM, Ángel González wrote:
There's also the middleground of not parsing the environment variables
before they are going to be used. That avoids the issues caused by
parsing what is not needed *and* doesn't break backwards compatibility.
See the patch I
Deron Meranda wrote:
On an unrelated note, I have also tried to compare sources against the
Savannah Git repository, and I noted that the repository has a couple small
differences from the FTP files + patches.
The Git repo has a blank file called -i, probably an accident of some
command
On Eric Blake wrote:
On 09/28/2014 10:31 AM, Ángel González wrote:
David A. Wheeler wrote:
2. Import environment variables *ONLY* when they are requested; do *NOT*
import them by default. Christos Zoulas has proposed this. This *IS* a
real backwards-incompatible change. But most
Linda Walsh wrote:
wrote:
The change only affects environment variables **loaded as exported
functions**. Bash won't forbid you from using / inside the name of an
environment variables.
The below doesn't demonstrate bash doing anything with the variable you
declared.
You
David A. Wheeler wrote:
2. Import environment variables *ONLY* when they are requested; do *NOT*
import them by default. Christos Zoulas has proposed this. This *IS* a real
backwards-incompatible change. But most users do *NOT* use this
functionality, and increasingly downstream systems
The change only affects environment variables **loaded as exported
functions**. Bash won't forbid you from using / inside the name of an
environment variables.
You can easily confirm with:
env -i 'foo/bar=baz' bash -c env
Best regards
Eric Blake wrote:
At any rate, this seems like an inadvertent regression that could be
patched; are you willing to propose such a patch? The gist of the
matter is that the code base must use the same decision on what forms a
valid function name as it does in deciding what exported
Steve Simmons wrote:
..bash_once defines SET_ONCE and loads literally hundreds of environment
variables and exports many shell functions that would otherwise have to be
defined in .bashrc and processed on every freaking run. .bash_once is about
50 times larger than .bashrc and .bash_login.
Chet Ramey wrote:
On 9/25/14, 2:47 PM, lolilolicon wrote:
On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
[...]
On the other hand, this approach would be much more interesting if bash
delayed parsing of exported functions until they are used (ie. check
This is what function
Eric Blake wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1141597 describes this bug
(aka CVE-2014-6271), and points out that even _with_ this patch, there
is still a flaw that attackers can use to overwrite portions of the
filesystem, which is also a possible exploitation avenue:
$ ls
Steve Simmons wrote:
IMHO, in this case, bash should do like zsh, which replaces the CR
character by the character sequence ^M.
This doesn't seem like a good idea. At our site it leads our zsh users
to send us complaints that they don't have a file with the two-character
name ^M.
libfaketime allows for easy testing of this bug:
LD_PRELOAD=/usr/lib/faketime/libfaketime.so.1 FAKETIME='-1y' \
FAKETIME_START_AFTER_SECONDS=1 TIMEFORMAT=%lR /bin/bash -c 'time sleep 2'
---
execute_cmd.c| 24
lib/sh/timeval.c | 5 -
2 files changed, 20
libfaketime allows for easy testing of this bug:
LD_PRELOAD=/usr/lib/faketime/libfaketime.so.1 FAKETIME='-1y' \
FAKETIME_START_AFTER_SECONDS=1 TIMEFORMAT=%lR /bin/bash -c 'time sleep 2'
---
execute_cmd.c| 24
lib/sh/timeval.c | 5 -
2 files changed, 20
36 matches
Mail list logo
