2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The Open
Group:
[...]
> |FWIW, a "printf %b" github shell code search returns ~ 29k
> |entries
> |(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\
> |ell)
> |
> |That likely returns only a small subset of
2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> > Well in all case %b can not change semantic in the bash script, since it is
> > there for so long, even if it depart from python, perl, libc, it is
> > unfortunate but that's the way it is, nobody want a semantic
2023-09-01 07:15:14 -0500, Eric Blake:
[...]
> > Note that in bash, you need both
> >
> > shopt -s xpg_echo
> > set -o posix
> >
> > To get a XSI echo. Without the latter, options are still
> > recognised. You can get a XSI echo without those options with:
> >
> > xsi_echo() {
> > local IFS='
2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> The current POSIX says that %b was added so that on a non-XSI
> system, you could do:
>
> my_echo() {
> printf %b\\n "$*"
> }
That is dependant on the current value of $IFS. You'd need:
xsi_echo() (
IFS=' '
2023-09-01 09:44:08 +0300, Oğuz via austin-group-l at The Open Group:
> On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> > My vote is for posix_printf %B mapping to libc_printf %b
>
> In the shell we already have bc for base conversion. Does POSIX really
> have to support C2x %b in the first
2023-09-01 07:13:36 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
> 2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> > In today's Austin Group call, we discussed the fact that printf(1) has
> > mandated behavior for %b (escape sequ
2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> In today's Austin Group call, we discussed the fact that printf(1) has
> mandated behavior for %b (escape sequence processing similar to XSI
> echo) that will eventually conflict with C2x's desire to introduce %b
> to
2023-07-07 15:52:28 -0400, Chet Ramey:
[...]
> Historical versions of test made the argument to -t optional here. I can
> continue to support that in default mode for backwards compatibility, but
> it will be an error in posix mode.
[...]
I think you may have overlooked the bottom part of my
Hello,
test -t X
Always returns false and doesn't report an error about that
invalid number (beside the point here, but in ksh/zsh, that X is treated
as an arithmetic expression and evaluates to 0 if $X is not set).
While:
test -t X -a Y
returns a "too many arguments" error.
test X -a -t -a
2021-02-14 18:02:52 +0700, Robert Elz:
[...]
> | I guess you are using Bash for so many years,
>
> Yes, since Paul Fox created and maintained it (version 1). It allowed
> me to escape from csh.
ITYM Brian Fox. Maybe the confusion comes from zsh's Paul
Falstad.
--
Stephane
2021-02-09 10:23:51 -0500, Chet Ramey:
[...]
> It's the assignment statement that's the oddball here; it's the only place
> where the exit status from a command substitution has any effect. This is a
> POSIX (maybe ksh) invention to provide assignment statements with a useful
> exit status.
[...]
2021-02-12 19:33:33 -0700, ron:
> In the Synopsis section, the builtin `caller` is not included. Several
> keywords are listed as builtins: [, if, until and while.
You're probably refering to the bash-builtins.1 man page shipped
with Debian. If you look at the bottom, you'll see that man page
is
Hello,
I was wondering why in my en_GB.UTF-8 locale, [0-9] matched
"only" on 1044 characters in bash 5.1 while in bash 4.4 it used
to match on 1050 different ones.
It turns out it's because since 5.0, the globasciiranges option
is enabled by default. Then I tried to understand what that
option
2020-05-27 10:19:35 -0400, Chet Ramey:
> Richard Stallman is looking for a shell programmer to assist with
> modifying a relatively complex script he uses to process messages and
> access a specific URL. The script is in perl, but he is worried about
> security issues processing URLs containing
2020-02-19 17:18:14 +0100, Ulrich Mueller:
[...]
> So, is there any syntax that allows to test if a value has been assigned
> to the array variable? Especially, to distinguish VARNAME=() (empty
> array) from VARNAME being unset?
[...]
You could do:
if typeset -p var 2> /dev/null | grep -q '=';
2019-12-24 12:16:41 -0500, Eli Schwartz:
[...]
> > Also note that sort -u and sort | uniq are not quite the same, the -u
> > option only considers the key fields when deciding which records (lines)
> > are unique (of course, with no key options, the whole line is the key,
> > in which case they
2019-11-18 20:46:26 +, Stephane Chazelas:
[...]
> > printf -v B '\u204B'
> > set -- ${B//?()/ }
> > echo "${@@Q}" #-> $'\342' $'\201' $'\213'
[...]
> It seems to me that zsh's approach is best:
>
> $ A=$'\u2048\201\u204
2019-11-17 01:25:31 -0800, Chris Carlen:
[...]
> # write 'REVERSE PILCROW SIGN' to B, then repeat as above:
> printf -v B '\u204B'
> set -- ${B//?()/ }
> echo "${@@Q}" #-> $'\342' $'\201' $'\213'
>
> # NOTE: Since there is only one character (under the UTF-8 locale),
> # this should have
2019-10-30 14:12:41 +0300, Oğuz:
[...]
> I was expecting
>
> bash -c '${1##*"${1##*}"}' _ foo
>
> to print an empty line too, but instead it prints foo.
[...]
> Is this a bug?
Yes,
In gdb, we see the ${1##*} expands to \177 (CTLNUL) as a result
of quote_string(). And that's used as is in the
Seems to be down to:
bash-5.0$ printenv SHLVL
1
bash-5.0$ printenv SHLVL | cat
0
Possibly a consequence of the fix for
https://lists.gnu.org/archive/html/bug-bash/2016-09/msg0.html
--
Stephane
2019-10-03 13:58:40 -0400, Chet Ramey:
> On 10/2/19 11:38 AM, Stephane Chazelas wrote:
>
> > BTW, what's the point of the check_dev_tty() function? It seems
> > it just attempts to open the tty (the controlling one or the one
> > open on stdin), closes it, but doesn
2019-10-03 02:49:36 +0900, Andrew Church:
> >Well, it's not so uncommon, I had it a few times. Reading on internet
> >it seems that other users have it but don't notice it.
>
> The fault could be in some other program accessing the terminal. Bash
> does not clear O_NONBLOCK on displaying a
2019-10-02 14:27:48 +0200, Matteo Croce:
[...]
> Sometimes bash leaves the pts with O_NONBLOCK set, and all programs
> reading from stdin will get an EAGAIN:
[...]
Can you reproduce it with
bash --norc
Or with:
INPUTRC=/dev/null bash --norc
?
If you could reproduce it with:
strace
2019-09-30 15:35:21 -0400, Chet Ramey:
[...]
> The $'\361' is a unicode combining
> character, which ends up making the entire sequence of characters an
> invalid wide character string in a bunch of different locales.
[...]
No, $'\u0361', the unicode character 0x361 (hex) is "COMBINING
DOUBLE
2019-09-27 16:52:50 -0700, Geoff Kuenning:
[...]
> $ mkdir /tmp/test$'\361'dir
> $ touch /tmp/test�dir/foo
> $ ls /tmp/test�dir/f*
> /tmp/test?dir/foo
> $ x=/tmp/test�dir
> $ echo "$x" | cat -v
> /tmp/testM-qdir
> $ ls "$x"/f*
> ls: cannot access '/tmp/test'$'\361''dir/f*': No such file or
2019-09-25 15:33:24 -0500, Eric Blake:
[...]
> Bash scripts often begin with @code{#! /bin/bash} (assuming that
> Bash has been installed in @file{/bin}), since this ensures that
> Bash will be used to interpret the script, even if it is executed
> -under another shell.
> +under another shell.
That's a a re-post of a bug report I raised a few years ago and
comes back now and then in various Q sites I participate in.
The discussions kind of trailed off last time.
https://www.mail-archive.com/bug-bash@gnu.org/msg17783.html
2016-02-24 15:16:41 +, Stephane Chazelas:
> $ time bash
2019-08-20 16:30:21 +0100, Stephane Chazelas:
[...]
> See also "filename generation" or "globbing" which avoid the
> potential confusion with ~user and <(...) which also are
> "pathname expansion" operators.
[...]
FWIW, in zsh's manual, "filen
2019-08-20 16:15:42 +0100, Stephane Chazelas:
[...]
> https://www.gnu.org/prep/standards/html_node/GNU-Manuals.html#GNU-Manuals
>
> GNU> Please do not use the term “pathname” that is used in Unix
> GNU> documentation; use “file name” (two words) instead. We use the
>
2019-08-20 10:08:10 -0400, Chet Ramey:
[...]
> However, at some point -- I can't find it now -- the GNU documentation
> standards recommended using "filename" and "filename expansion," reserving
> "pathname" for colon-separated values like $PATH.
[...]
I think you're refering to:
2019-08-08 10:38:48 -0400, Greg Wooledge:
[...]
> > shopt -s failglob
> > command="echo xyz\(\)"
> > $command
> > ```
> >
> > And it was working fine. But somewhere between bash version 4 and 5 I
> > realized it generates an error:
> > no match: xyz\(\)
[...]
> And my personal response for this
[re-post via gmane as the usenet interface seems not to work
again. My posts can be seen at
https://groups.google.com/forum/#!topic/gnu.bash.bug/0JgBRq_778o
but were apparently not forwarded to the mailing list]
2019-08-06 16:00:21 -0400, Greg Wooledge:
> On Tue, Aug 06, 2019 at 06:18:27PM +,
2019-07-29 17:55:58 +0100, Isabella Bosia:
> haven't really looked into why this happens but x[ seems to trigger some
> funny parser behavior
>
> x[ newline should not prompt with PS2
>
> it can't be defined as a normal sh function, but it can be defined with the
> function keyword
[...]
x[
2019-07-28 21:17:43 -0700, L A Walsh:
> Is there a T/F var expansion that does:
>
> var=${tst:+$yes}${tst:-$no}
>
> but with yes/no in 1 expansion?
[...]
You can also do:
no_yes=(no yes)
echo "${no_yes[${var+1}]}"
For the reverse:
echo "${no_yes[!0${var+1}]}"
See also:
map=(unset
2019-07-22 14:55:05 -0500, Eric Blake:
[...]
> > Even if POSIX didn't mandate
> >
> > printf -- -%s x
> >
> > to output -x, I'd say it would be a bug in the POSIX
> > specification (it looks like it is).
>
> POSIX _does_ mandate 'printf -- -%s x' to output exactly '-x', by virtue
> of the fact
2019-07-23 00:56:59 +0700, k...@munnari.oz.au:
[...]
> POSIX specifies that printf(1) has no options, and by not
> specifying that it is intended to comply with XBD 12.2 effectivly
> says that it is not. That is, in printf, the first arg is
> always the format string,
2019-07-05 09:03:06 -0400, Chet Ramey:
[...]
> > Second, when ran in a subshell, the same exit status gets mapped to 255.
> > While logical, as -1 gets mapped to 255, it seems inconsistent.
> > ( from the manual: "The return status is the exit status of list." )
>
> It's the
One can use:
IFS= read -i "$var" -red $'\r' var
In bash as the equivalent of zsh's
vared var
To edit the content of a variable (with the added restriction
that $var can't contain CR or NUL characters), using ^V^J to
embed newline characters.
But I find that after I run that command
2018-08-15 11:05:06 -0400, Chet Ramey:
> On 8/14/18 11:50 AM, Stephane Chazelas wrote:
> > Hi,
> >
> > This is from
> > https://unix.stackexchange.com/questions/462333/why-does-a-in-bin-sh-a-affect-sed-and-set-a-doesnt
> > (original investigation by Mark Plotnic
2018-08-14 11:25:04 -0400, Chet Ramey:
[...]
> If you build a profiling version of bash, you'll find that about 75% of
> that time is spent copying the list of arguments around, since you have
> to save and restore it each time you call f1. Looking at making that more
> efficient has been a
Hi,
This is from
https://unix.stackexchange.com/questions/462333/why-does-a-in-bin-sh-a-affect-sed-and-set-a-doesnt
(original investigation by Mark Plotnick)
Though not documented, enabling the POSIX mode in bash whether
with
- bash -o posix
- sh
- env SHELLOPTS=posix bash
- set -o posix #
Note: sent to bash, zsh and Schily Bourne shell dev mailing
lists (not mksh as my email provider apparently doesn't play
well with mirbsd.org's expensive greylisting, please feel free
to forward there if you don't use gmail).
That's from:
2017-12-04 08:46:24 -0500, Chet Ramey:
[...]
> Bash-4.4 allows you to wait for the last process substitution, since the
> pid appears in $!, like ksh93.
Thanks,
I hadn't noticed it had changed in 4.4
One major differnce with ksh93 though is that it won't work with
cmd | tee >(cmd2)
unless you
2017-12-03 17:31:00 -0500, Chet Ramey:
> On 12/1/17 2:00 PM, Stephane Chazelas wrote:
>
> > Also, there's a lot of problems reported at
> > unix.stackexchange.com at least that are caused by bash not
> > waiting for the processes started by process substitutions,
> &
FYI,
as seen at https://unix.stackexchange.com/a/408171, there are
still a few "problems" with process substitution, where some fds
are closed where they probably shouldn't:
> Note that even with the latest (4.4.12 as of writing) version, bash still has
> a few bugs here like:
>
> $ bash -c
Hello,
$ bash -c 'for ((i = 0; $(echo 0); i++)); do echo x; done'
(OK)
$ bash -c 'for ((i = 0; ${x-`echo 0`}; i++)); do echo x; done'
(OK)
$ bash -c 'for ((i = 0; ${x-$(echo 0)}; i++)); do echo x; done'
bash: -c: line 0: syntax error near unexpected token `newline'
bash: -c: line 0: `for ((i
2015-01-22 14:43:00 +, Stephane Chazelas:
[...]
> Bash Version: 4.3
> Patch Level: 30
> Release Status: release
>
> (Debian unstable amd64)
>
> $ LC_ALL=tr_TR.UTF-8 bash -c 'typeset -l a; a=İ; echo $a' | hd
> 69 b0 0a
2017-09-17 11:01:00 +0100, Stephane Chazelas:
[...]
>wchar_t wc;
> - size_t mblength, slen;
> + int mblength;
[...]
> + mblength = mbtowc (, garglist->word->word+1, slen);
> + if (mblength > 0)
> +ch = wc;
[...]
Actually, "wc" should probably b
Sorry, subject was wrong. The behaviour is OK in the C locale.
--
Stephane
$ locale charmap
UTF-8
$ bash -c '"$@"' sh printf '%d\n' $'"\xff' $'"\xff' $'"\xff'
32767
0
0
That's because we store the return value of mblen() (which may be
-1) into a size_t (unsigned) variable.
See patch below which aligns the behaviour with that of other
shells which use the byte value
2017-09-10 14:56:50 -0400, Chet Ramey:
> On 9/10/17 11:11 AM, Stephane Chazelas wrote:
> > When running bash as:
> >
> > bash -s foo bar
> >
> > "$@" is not available inside .bashrc. Same for $ENV (POSIX
> > conformance issue?), $BASH_
When running bash as:
bash -s foo bar
"$@" is not available inside .bashrc. Same for $ENV (POSIX
conformance issue?), $BASH_ENV, or ~/.bash_profile (with bash
--login -s).
In the case of bash -c, that also affects $0.
ksh88, ksh93, mksh, dash, zsh, posh, busybox sh can access $@ in
$ENV
Using "read -N" on text containing multi-byte characters
produces incorrect result.
On Debian amd64 with the latest code from git:
$ locale charmap
UTF-8
$ printf '\ue9VWXYZ' | ./bash -c 'IFS= read -rN4 a; printf %s "$a"' | hd
c3 58 a9 56 57|.X.VW|
2017-03-20 16:32:10 -0400, Chet Ramey:
[...]
> > See also:
> >
> > $ bash -c 'f() { unset a; echo "$a";}; a=1; a=2 f'
> > 1
> >
> > already mentioned.
>
> A distinction without a difference; the behavior is explicitly the same.
[...]
One I haven't mentioned yet is:
$ bash -c 'f() { local a;
2017-03-20 14:47:17 -0400, Chet Ramey:
> On 3/20/17 2:30 PM, Eric Blake wrote:
> > On 03/17/2017 07:21 PM, Stephane Chazelas wrote:
> >
> >>> The problem is the non-obvious nature of unset's interaction with scope,
> >>
> >> the main problem
2017-03-20 08:04:33 -0400, Greg Wooledge:
[...]
> > Credits to Dan Douglas
> > (https://www.mail-archive.com/miros-mksh@mirbsd.org/msg00707.html)
> > for finding the bug. He did find a use for it though (get the
> > value of a variable from the caller's scope).
>
> Isn't this exactly the same as
2017-03-20 12:30:09 +0900, 渡邊裕貴:
> It seems to me this matter is specific to the IFS variable (and possibly
> few others like CDPATH). Unsetting IFS restores the default field splitting
> behavior, but unsetting PATH does not restore the default command search
> path. As Peter suggests, you can
2017-03-19 18:05:19 -0400, Chet Ramey:
> On 3/19/17 5:51 PM, Stephane Chazelas wrote:
>
> > On comp.unix.shell ot http://unix.stackexchange.com, I've posted
> > many articles describing how to do splitting in POSIX-like
> > shells:
> >
> > ( # subshell
2017-03-18 13:16:56 -0400, Chet Ramey:
> On 3/17/17 5:51 PM, Stephane Chazelas wrote:
>
> > Now, if that "split" functions is called from within a function
> > that declares $IFS local like:
> [...]
> > because after the "unset IFS", $IFS is n
2017-03-17 17:35:36 -0500, Dan Douglas:
> The need to localize IFS is pretty obvious to me - of course that's
> given prior knowledge of how it works.
[...]
I don't expect the need to have to add "local var" in
(
unset -v var
echo "${var-OK}"
)
would be obvious to many people beside you
Hi,
consider this function:
split() (
unset -v IFS # default splitting
set -o noglob # disable glob
set -- $1 # split+(no)glob
[ "$#" -eq 0 ] || printf '<%s>\n' "$@"
)
Note the subshell above for the local scope for $IFS and for
the noglob option. That's a common idiom in POSIX shells
2017-03-03 08:27:03 -0500, Chet Ramey:
> On 3/1/17 4:58 PM, Stephane Chazelas wrote:
>
> > BTW, there seems to have been a regression in the handling of the -O
> > option to the bash interpreter:
>
> Thanks, I'll take a look. It looks to be specific to the various
>
2017-03-01 09:49:52 -0500, Chet Ramey:
[...]
> > Would you recommend people start adding:
> >
> > shopt -s compat44 2> /dev/null || true
> >
> > at the start of their script that they develop for bash-4.4 now
> > so that it still works even when bash-6.0 makes a non-backward
> > compatible
2017-02-28 16:18:05 -0500, Chet Ramey:
[...]
> > Just my personal opinion, but I think I'd rather the spec had
> > been updated to accomodate the bash (and many other shells)
> > behaviour rather than bash breaking its backward compatibility
> > to comply to a requirement that is not particularly
2017-02-28 19:43:11 +0100, tarot:
> Gr! it is not a bug!!!
>
>
> xx. Fixed a bug that could allow `break' or `continue' executed from shell
> functions to affect loops running outside of the function.
>
> My BIG script doesn't work with bash-4.4
>
There was a related discussion on
2017-02-27 16:18:46 -0500, Chet Ramey:
> On 2/27/17 11:50 AM, Martijn Dekker wrote:
>
> > So basically you're saying that, for options without a single-letter
> > equivalent, "-o" options are those that are either POSIX or that you
> > think should be POSIX? But then that distinction is more
2017-02-06 09:45:26 +0530, Jyoti B Tenginakai:
[...]
> Again I see that this printf we can use. But there are some scenarios where
> the o/p does not exactly match with echo. So still its good to have a way
> to pirnt -n /-e/-E with echo. Can this be considered as bug and can this be
> fixed?
2017-02-02 22:26:22 +0530, Jyoti B Tenginakai:
[...]
> I have tried using the printf instead of echo. But the issue with printf
> is , the behaviour is not consistent with what echo prints for all the
> inputs i.e.
> In my script I am generically using echo for all the options. If I have to
> use
2016-12-21 14:35:44 +, Stephane Chazelas:
[...]
> That sync_buffered_stream is meant to seek back to where we're
> meant to resume reading the script when we've read more than
> needed, but here b_inputp > b_used would suggest we've processed
> code that is passed what we'v
Hello.
That was discovered at
http://unix.stackexchange.com/a/331884
Consider this script that modifies itself (and happens not to
end in a newline character):
$ printf %s 'printf "\necho %s\n" {1..10} >> $0' > script.sh; bash -x
./script.sh
+ printf '\necho %s\n' 1 2 3 4 5 6 7 8 9 10
+ echo 1
2016-11-04 12:29:03 +, Stephane Chazelas:
[...]
> $ LC_ALL=zh_HK.big5hkscs locale charmap
> BIG5-HKSCS
>
> Most of the problematic characters are the ones ending in 0x5c
> (which happens to be backslash in ASCII (or in BIG5-HKSCS when
> standing alone).
[...]
Those c
(reproduced with bash 4.3 or 4.4 on Debian unstable and Ubuntu 16.04).
perl -le "printf q([[ $'\U%X' = $'\U%X' ]] || echo %06X: $'\U%X').\"\n\",
\$_,\$_,\$_,\$_ for (1..0xd7FF, 0xE000..0x10)" |
LC_ALL=zh_HK.big5hkscs bash | LC_ALL=C sed -n l
Where the perl command outputs:
[[ $'\U1' =
2016-10-08 17:33:00 +0200, Conrad Hoffmann:
[...]
> $ TEST=5; echo $((--TEST+++3)) # outputs 7
>
> However, due to the documented operator precedence, I would have
> expected that expression to be equal to:
>
> $ TEST=5; echo $((--(TEST++)+3)) # outputs 8
>
> Instead, though, it seems to be
2016-09-30 04:49:33 +0100, Martijn Dekker:
[...]
> my_subshell_pid=$(sh -c 'echo $PPID')
>
> This works fine on every shell, except on bash when a dot script is
> being executed.
[...]
While it does look like a bug, you could always do:
my_subshell_pid=$(exec sh -c 'echo $PPID')
To be
That's a special case of the
[[ "\\" =~ ["."] ]]
returning true (because bash called regcomp("[\\.]") instead of
regcomp("[.]") I had reported some time ago and was then fixed.
Here. It's similar:
$ bash -c '[[ "\\" =~ [^]"."] ]]' || echo unexpected
unexpected
$ ltrace -e regcomp bash -c '[[
Hello,
that came up when discussing a related bug in zsh
(http://www.zsh.org/mla/workers/2016/msg01574.html)
$SHLVL is a feature introduced by tcsh (at least some patches on
tcsh) in the early eighties, that is meant to represent the
depth of a stack of shells executing each other.
It's not
2016-08-23 12:26:37 -0400, Greg Wooledge:
[...]
> > ksh -c '((0)); echo X'
> >
> > outputs X
>
> You forgot the -e. Here's ksh88:
>
> $ ksh -e -c '((0)); echo X'
> $ uname -a
> HP-UX imadev B.10.20 A 9000/785 2008897791 two-user license
[...]
Oops.
I did test with -e on Solaris though
$
2016-08-12 14:22:32 -0400, Chet Ramey:
[...]
> The relevant change was probably the change in the set of commands to which
> `set -e' applies. The (( command (among others) was added to that list
> in bash-4.1. The change was the result of Posix changing the semantics
> of the errexit option and
bash treats all blank characters in the locale (except
multibyte ones, bug reported earlier) as token delimiters.
Yet printf %q only quotes space and tab, not the other ones.
For instance, on Solaris in locales using the iso8859-1
character set, 0xa0 (non-breaking space) is a single-byte blank
2016-04-13 11:23:01 +, Anis ELLEUCH:
> Hello everybody,
>
> I would like to ask if it is possible to disable expanding asterisk when it
> selects all entries ?
>
> `$ rm * .jpg` with a mistaken space between asterisk and .jpg will delete
> everything in your home directory or in the entire
2016-04-13 08:55:16 -0400, Greg Wooledge:
[...]
> > And if you want to keep eventual spurious characters after the
> > last NL character in the file:
> >
> > while IFS= read -r line; do printf '%s\n' "$line"; done < test.txt
> > [ -z "$line" ] || printf %s "$line"
>
> Another way to write that
2016-04-13 08:10:15 +0200, Geir Hauge:
[...]
> while read -r line; do echo "$line"; done < test.txt
>
> though printf should be preferred over echo:
>
> while read -r line; do printf '%s\n' "$line"; done < test.txt
[...]
Actually, you also need to empty $IFS
while IFS= read -r line; do
2016-03-17 09:00:37 -0600, Eric Blake:
[...]
> That said, if you WANT an error if 'two/' does not exist, and to move
> 'one' to 'two/one' if 'two/' does exist, you can always use:
>
> mv one two/.
>
> where the trailing '.' changes the semantics required of the rename()
> call, and forces an
2016-03-09 08:04:33 -0500, Chet Ramey:
> On 3/8/16 6:04 AM, Isabella Parakiss wrote:
>
> >
> > This seems to be a related problem:
> > $ time (exec true) # doesn't print anything
>
> Timing is an attribute associated with a command. In this case, that's the
> simple command (`exec
2016-03-07 08:58:05 +0100, Isabella Parakiss:
[...]
> OTOH this is arguably more useful than its ksh equivalent:
> GLOBIGNORE=-*; some-cmd *; some-cmd ./*
[...]
True, that's probably the one case where the GLOBIGNORE
behaviour is actually useful.
Note that with ksh93, you've got to write it:
Today, I realised that GLOBIGNORE doesn't work at all like ksh's
FIGNORE.
With
GLOBIGNORE=x*
we're not filtering out files whose *name* starts with "x" from
globs but those whose *path* starts with "x".
In
echo *
files whose name starts with "x" will be excluded, but not in
echo ./*
I
2016-03-06 22:16:58 +, Stephane Chazelas:
[...]
> $ bash -c 'GLOBIGNORE=x*; echo .*'
> .*
> $ bash -c 'GLOBIGNORE=x*; echo ./.*'
> ./. ./..
> $ bash -c 'GLOBIGNORE=x*; echo .*/a'
> ./a ../a
>
> To truely exclude . and .., one needs:
>
>
2016-02-25 10:48:51 -0500, Chet Ramey:
[...]
> Because bash doesn't have floating point arithmetic.
Yes, makes sense. mksh having $EPOCHREALTIME floating point even
though it doesn't have floating point arithmetic does sound
weird.
Any plan of adding floating point arithmetic support to bash by
$ time bash -c 'while ((SECONDS < 1)); do :; done'
bash -c 'while ((SECONDS < 1)); do :; done' 0.39s user 0.00s system 99% cpu
0.387 total
That can take in between 0 and 1 seconds. Or in other words,
$SECONDS becomes 1 in between 0 and 1 second after the shell was
started.
The reason seems to
[...]
> Reproduced with 4.2.53 on Debian:
[...]
Actually, it was already reported in early 2013 and fixed for
4.3:
http://thread.gmane.org/gmane.comp.shells.bash.bugs/19384
--
Stephane
2016-02-15 09:31:57 -0500, Chet Ramey:
> On 2/15/16 8:57 AM, Pontus Stenström wrote:
>
> > Bash Version: 4.2
> > Patch Level: 24
> > Release Status: release
> >
> > Description:
> > Comma expression in arithmetic evaluation referring to arrays make bash
> > crash.
> >
> > Repeat-By:
> >
2016-02-08 09:00:09 -0500, Chet Ramey:
> On 2/8/16 2:47 AM, Linda Walsh wrote:
> > When you are doing a var expansion using the
> > replacement format ${VAR//./.}, is there some way to
> > put parens around some part of the expression and reference
> > them as in the [[V~re]] RE-matches?
>
> No.
2016-02-03 23:43:37 +, Martijn Dekker:
> bash treats an empty array as if it were an unset variable, which seems
> very illogical as empty is quite distinct from unset:
>
> $ myarray=()
> $ [[ -v myarray ]] && echo set || echo unset
> unset
[[ -v var ]] is for scalar variables (AFAICT).
bash
2016-01-18 11:25:49 -0500, Greg Wooledge:
[...]
> Other shells must go out of their way to suppress it, then.
>
> wooledg@wooledg:~$ while IFS= read -r -d '' foo; do echo "<$foo>"; done <
> <(printf 'one\0two\0')
>
>
> wooledg@wooledg:~$ ksh
> $ while IFS= read -r -d '' foo; do echo "<$foo>";
2016-01-18 11:16:06 -0500, Chet Ramey:
[...]
> > But it's
> > an incredibly useful feature, and has been used in countless real
> > life scripts. At this point, while it is still undocumented, it is
> > nevertheless a feature whose omission would be considered a regression.
>
> It's not a
2015-12-22 08:16:28 -0500, Greg Wooledge:
[...]
> t=946702800 # Start at Sat Jan 1 12:00:00 EST 2000
> endyear=2036
>
> while true; do
> printf -v year '%(%Y)T' "$t"
> ((year > endyear)) && break
> printf -v day '%(%d)T' "$t"
> printf -v dow '%(%w)T' "$t"
> if [[ $day = 13 && $dow
2015-12-19 00:58:41 +0100, Piotr Grzybowski:
> Thanks for taking time to answer. Of course it is the issue of
> programming style (isnt it true that most things can be brought down
> to the programming style?), two real-life examples (stripped-down of
> everything):
>
> #1
> if [ -f
2015-12-16 16:03:14 +0100, Piotr Grzybowski:
> Dear All,
>
> one thing I missed for some time now, is the ability to access the
> argument passed to test, or any argument on the right hand side.
> I needed it so I made a quick hack, which I attach as a reference.
> It allows to access arg in
2015-12-15 09:01:05 -0500, Chet Ramey:
> On 12/14/15 6:30 PM, up201407...@alunos.dcc.fc.up.pt wrote:
> > Quoting "Stephane Chazelas" <stephane.chaze...@gmail.com>:
> >
> > I understand what you're saying.
> > As much as we would like, there's no way
2015-12-15 00:30:16 +0100, up201407...@alunos.dcc.fc.up.pt:
[...]
> >Should we also block SHELLOPTS=history
> >HISTFILE=/some/file like /proc/$pid/fd/$fd and
> >TZ=/proc/$pid/fd/$fd (like for your /bin/date command) as that
> >allows DoS on other processes (like where those fds are for
> >pipes).
1 - 100 of 360 matches
Mail list logo
