On Tue, Aug 06, 2024 at 03:58:35PM -0400, Chet Ramey wrote:
> [...] Bash has never looked at
> anything but whole seconds. [...]
>
Ok, cool. So this is not a bug but rather just how Bash works. That's
fine but then I think the documentation could reflect the actual
behaviour better
tent with the observed behavior.
>
I agree! It's the truncating part that is the cause of this
confusion.
> However, I agree that this is implicit and ambiguous. A minimal
> modification is probably something like
>
> diff --git a/doc/bash.1 b/doc/bash.1
> index 1f0a23d3..3ace21e9
Reading the manual at
<https://www.gnu.org/software/bash/manual/bash.html#Bash-Variables>
regarding the SECONDS variable, it states that
" [..] Assignment to this variable resets the count to the value assigned,
and the expanded value becomes the value assigned plus the number
of se
From: Naïm Favier
Currently, typing `cmd flag1 flag2` (note the two spaces), navigating
between the two spaces and hitting Tab produces
`COMP_WORDS=(cmd flag1 flag2)` without inserting an empty word between
flag1 and flag2.
I believe this comes from considering the cursor ("sentinel") as a bloc
Variable transforms such as ${VAR@Q} do not compose with substrings
expansions, eg ${VAR:1:4}.
For example, I expected ${VAR:4@Q} to quote ${VAR:4}, but instead:
-bash: VAR: 4@Q: value too great for base (error token is "4@Q")
This is because parameter value modifiers do n
Hi Lawrence:
On Fri 7/3/20 14:03 -0400 =?utf-8?Q?Lawrence_Vel=C3=A1zquez?= wrote:
>What's wrong with `foo | tee /dev/stderr | bar`?
Perfect!
This morning I had thought of
foo | tee >(cat >&2) | bar
but your soln is simplier. I assume /dev/stderr is on non linux UNIX
also.
--
thanks-you!,
This does what I want:
--8<---cut here---start->8---
_tee_stderr ()
{
<<'eohd'
SYNOPSIS
ourname
DESCRIPTION
Use in a pipe. Leaks STDIN to STDERR. Passes STDIN to STDOUT unchanged.
EXAMPLE
$ seq 5 |_tee_stderr
Hi,I'm having some difficulties with the file access time and the file
modification time. Scripts are attached for your convenience.Regards,Mischa
Baars.Sent from my Samsung Galaxy smartphone.
conditional.sh
Description: application/sh
accesstime.sh
Description: application/sh
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_VE
3:14
CEST 2019 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 7
Release Status: maint
all other details got lost when I answered 'n' to:
Send bug report to bug-bash@gnu.org? [y/n]
(and I don't feel like typing all that again)
but all
Hi,
I've been searching the BASH manual (
https://www.gnu.org/software/bash/manual/bash.html) to find out about the
precedence/sequence that the shell parses commands. The particular question
I've had which I was helped with:
https://unix.stackexchange.com/questions/526646/precedence-of
On 9/25/18 3:46 PM, Chet Ramey wrote:
> On 9/25/18 9:04 AM, dirk+b...@testssl.sh wrote:
>
>> FYI: I ended up checking with type before whether an external printf
>> exists and set a variable for this and then just call this variable.
>>
>> env or exec: never thought about it (thanks!) but as bo
On 9/23/18 8:26 PM, Chet Ramey wrote:
> On 9/22/18 4:22 PM, Bob Proulx wrote:
>
>> Note that I *did* provide you with a way to do what you wanted to do. :-)
>>
>> It was also noted in another message that the external standalone
>> printf command line utility did buffer as you desired. That see
On 9/22/18 12:30 PM, Ilkka Virta wrote:
> The coreutils printf seems to output 'foo\nbar\n' as a single write, though
> (unless
> it goes to the terminal, so the usual stdio buffering), so you might be able
> to use
> that.
thx. Might be not that portable but we'll see.
> In any case, if a
On 9/22/18 12:38 PM, Ilkka Virta wrote:
> On 22.9. 02:34, Chet Ramey wrote:
>> Newline? It's probably that stdout is line-buffered and the newline causes
>> a flush, which results in a write(2).
>
> Mostly out of curiosity, what kind of buffering logic does Bash (or
.
Do you think there should be a paragraph NOT COMMON where bash sockets
should rather belong to?
> More
> typically one would use a C program instead. So it isn't surprising
> that you are finding interactions that are not well known.
Bob, my intention was not to discuss program lang
00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0a\...'
>>
>> Each \x0a like the last one causes a new TCP fragment to begin which can be
>> easily
>> spotted when using wireshark while running e.g.
>
> Newline? It's probably that stdout is line-buffered and the n
me-http -p testssl.sh
Starting from the SSLv3 ClientHello the first reassembled packet
ends with 0a.
See also discussion @ https://github.com/drwetter/testssl.sh/pull/1113.
One would assume that a bash socket connection cannot influence the TCP
fragmentation but obviously it does.
This behavior has
No response today from bug-recutils:
http://lists.gnu.org/archive/html/bug-recutils/2017-11/msg4.html
For the ./configure, I untarred the latest bash source into a subdir, and set
--with-bash-headers=
to that pathname.
Perhaps someone with an understanding of GNU configure/autoconf
${}.
>
> > Repeat-By:
> > $ declare -A array
> > $ exec {array[key]}
> [...]
>
> In the documentation, it's {VARNAME} documented.
>
> zsh doesn't support {array[key]}
> ksh does though it's not documented (documented the same as
> bash).
>
t; beginning of the line or a quote character up to point.
If it considered characters from the beginning of the line,
then there would be no issue. The backtick is inside an
open single quote, and the backtick is *not* a special
character under that circumstance -- it's no more special
to Bash
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_VE
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_VE
scripts with 'set -xv' is helpful in figuring out this
sort of thing.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
es) are
usually done in Perl now. So it really isn't a matter of "coding"
but more about convenience at interactive command-line.
Thanks for your input anyhow.
Regards
Bahser
_______
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
hould have been named EFS?
Anyhow I see that bash has taken the liberty of changing
the traditional acronym expansion from "Input Field Separator" to
"Internal Field Separator". A subtle difference.
But the word "Internal" isn't quite as good as "Expansion&q
vi
$(grep
-l
PATTERN
*)
Or is IFS not really an IFS?
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
e hoped that the IFS was interpreted after its delimiter
has been encountered, so that the single line example would work.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
r the vi, but not for the command
>substitution. Break your result into two commands:
>
>IFS='\n'
>vi $(grep -l PATTERN *)
>
But dont variables set on command line apply to everything on
that line?
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
>>> $ cat x3
>>> [ -d scratch ] || mkdir scratch
>>> cd scratch
>>> touch 'a b w' 'c d x' 'e f y' 'g h z'
>>>
>>> IFS=$'\n'
>>> recho $(ls -1 *)
>>> $ ../bash-3.2/bash ./x
;s sufficient. Second,
>arrange things so that the shell won't split words on anything but
>newline, your desired delimiter.
>
>Take a look at the approach in the following example script. `recho' is
>part of the bash distribution; it's built while running the test suite.
&
tant than safety,
especially when using the term "safe" is used in such a loose and
non-specific way.
i
>
>> It is bash (and others) which quite deliberately
>> reduce available information by converting all newlines and whitespace
>> into a single space.
>
>Only
hat find is clever enough to assemble arguments containing
spaces into an arglist and feeding them to vi, why can't bash?
Regards
Bahser
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
#x27;t it?
But then why not just:
grep -l PATTERN *.c | while read f; do vi "$f"; done
This is a bash mailing list isn't it!
Regards
Bahser
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
s should be adjusted to account for
bash/POSIX deficiencies? No.
>This is probably not a an optimal solution because this is late night
>time for me but this works:
>
> eval vi $(grep -l PATTERN * | sed 's/ /\\ /')
>
Yes, that works.
But surely such a grotesque syntax is not
be too difficult?
Regards
Bahser
_______
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
ted by matching
double-quote.
Ok, so that means that the above is:
"$(basename "
followed by:
$f1
followed by:
")"
which means that any spaces in $f1 are apparently unquoted and will
therefore be subject to arg splitting.
echo "one=$file"
done
for file in "`basename \"$f1\"`"*.ext "`basename \"$f2\"`"*.ext
do
echo "two=$file"
done
---
The backticks work perfectly.
But the $() gets it very wrong and leaves a double-quote in t
that. Doesn't work.
Perhaps instead of just saying "Use IFS..." you could show
me a working example.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: darwin9.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc' -
DCONF_OSTYPE='darwin9.0' -DCONF_MACHTYPE='powerpc-apple-darwin9.0' -
DCON
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=&
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
information.
File name: message.pif
Virus name: W32/[EMAIL PROTECTED]
Copyright © 1993-2003, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.mcafeeb2b.com
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo
information.
File name: message.scr
Virus name: W32/[EMAIL PROTECTED]
Copyright © 1993-2003, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.mcafeeb2b.com
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo
45 matches
Mail list logo
