On Sat, 12 Oct 2024, 23:50 Saint Michael, wrote:
> From: Saint Michael
> Date: Sat, Oct 12, 2024 at 9:49 AM
> Subject: New feature
>
> The command printf needs a new flag, -e, that would mimic that way the
> same flag works with echo.
> …
> PROCEDURE_INFO=$(echo -e &qu
On Okt 12 2024, Saint Michael wrote:
> After using printf, right now I need to lunch a second command if I
> need to expand the \n into real new lines.
$ printf %b '\n'
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now fo
On Sat, Oct 12, 2024 at 09:50:03 -0400, Saint Michael wrote:
> The command printf needs a new flag, -e, that would mimic that way the
> same flag works with echo.
> After using printf, right now I need to lunch a second command if I
> need to expand the \n into real new lines.
>
> PROCEDURE_INFO=
From: Saint Michael
Date: Sat, Oct 12, 2024 at 9:49 AM
Subject: New feature
The command printf needs a new flag, -e, that would mimic that way the
same flag works with echo.
After using printf, right now I need to lunch a second command if I
need to expand the \n into real new lines
Hello.
Thank you. If you don't want to implement it yourself, I am at your
disposal. :) Just let me now.
Best regards
Přemysl
On 9/1/21 4:11 PM, Chet Ramey wrote:
On 8/31/21 3:25 PM, Lawrence Velázquez wrote:
On Tue, Aug 31, 2021, at 4:02 AM, Lawrence Velázquez wrote:
ksh does not blindly
On 8/31/21 3:25 PM, Lawrence Velázquez wrote:
> On Tue, Aug 31, 2021, at 4:02 AM, Lawrence Velázquez wrote:
>> ksh does not blindly remove all leading whitespace
>
> For the curious, this is how ksh(1) describes it:
>
> If '#' is appended to '<<', then leading spaces and tabs
> will b
On Tue, Aug 31, 2021, at 4:02 AM, Lawrence Velázquez wrote:
> ksh does not blindly remove all leading whitespace
For the curious, this is how ksh(1) describes it:
If '#' is appended to '<<', then leading spaces and tabs
will be stripped off the first line of the document and up
31 Ağustos 2021 Salı tarihinde Jesse Hathaway yazdı:
> On Tue, Aug 31, 2021 at 2:24 AM Přemysl Šťastný wrote:
> >
> > Thanks for advice. How do you use it in more detail please?
>
> You can feed shfmt an individual file to format, it defaults to
> using tabs for indentation:
>
> $ shfmt ~/test
On Tue, Aug 31, 2021 at 2:24 AM Přemysl Šťastný wrote:
>
> Thanks for advice. How do you use it in more detail please?
You can feed shfmt an individual file to format, it defaults to
using tabs for indentation:
$ shfmt ~/test.sh
#!/bin/bash
cat <<-EOF
hello!
EOF
Or you can instru
Hi,
> ... ignoring both leading spaces and leading tabs. eg.
Something like (there must be nothing but tabulation before closing ``EOF'')?
func(){
sed 's/^ \{2\}//' <<- EOF
blabla
EOF
}
Depending on how and why, there is a lot of *variants*:
- leading spaces and/or/not
> On Aug 31, 2021, at 3:16 AM, Přemysl Šťastný wrote:
>
> I didn't realize yesterday, that ksh93 is not a nick name, but ksh version
> 93. :D
Sort of.
> So it would be okey with you, if I try to implement it using <<#?
The bash maintainer (who is not me) hasn’t yet indicated whether this is
Thanks for advice. How do you use it in more detail please?
On 8/30/21 11:48 PM, Jesse Hathaway wrote:
Will ksh93 version ever get to upstream? This ugly 'bug' is here for
decades and really irritates me and many people, who ever used shell for
larger scripting and don't like to use tabs.
I use
I didn't realize yesterday, that ksh93 is not a nick name, but ksh
version 93. :D
So it would be okey with you, if I try to implement it using <<#?
Is there any git repo of bash?
Thanks.
P.
On 8/30/21 11:43 PM, Lawrence Velázquez wrote:
On Mon, Aug 30, 2021, at 5:22 PM, Přemysl Šťastný wrote
> Will ksh93 version ever get to upstream? This ugly 'bug' is here for
> decades and really irritates me and many people, who ever used shell for
> larger scripting and don't like to use tabs.
I used to always prefer spaces, until I switched to auto formatting all my Bash
scripts with shfmt[1]. It
On 30/08/2021 09:28 pm, Greg Wooledge wrote:
On Mon, Aug 30, 2021 at 10:06:37PM +0200, Přemysl Šťastný wrote:
I think, it would be nice, if you implemented Squiggly heredoc, which solves
this problem by ignoring both leading spaces and leading tabs. eg.
func()(
cat <<~ EOF
blabla
EOF
On Mon, Aug 30, 2021, at 5:22 PM, Přemysl Šťastný wrote:
> Will ksh93 version ever get to upstream?
I don't know what you mean by that. ksh is not "downstream" of
bash; it is a separate project. Whether bash incorporates this
feature or one like it is up to Chet, who hasn't yet chimed in.
> Thi
Hi.
Thank for your answer.
Will ksh93 version ever get to upstream? This ugly 'bug' is here for
decades and really irritates me and many people, who ever used shell for
larger scripting and don't like to use tabs.
Best regards
P.
On 8/30/21 11:14 PM, Lawrence Velázquez wrote:
On Mon, Aug 3
On Mon, Aug 30, 2021, at 4:06 PM, Přemysl Šťastný wrote:
> I think, it would be nice, if you implemented Squiggly heredoc, which
> solves this problem by ignoring both leading spaces and leading tabs. eg.
>
> func()(
> cat <<~ EOF
> blabla
> EOF
> )
'<<~' is already syntactically vali
On Mon, Aug 30, 2021 at 04:28:40PM -0400, Greg Wooledge wrote:
> On Mon, Aug 30, 2021 at 10:06:37PM +0200, Přemysl Šťastný wrote:
> > I think, it would be nice, if you implemented Squiggly heredoc, which solves
> > this problem by ignoring both leading spaces and leading tabs. eg.
> >
> > func()(
On Mon, Aug 30, 2021 at 10:06:37PM +0200, Přemysl Šťastný wrote:
> I think, it would be nice, if you implemented Squiggly heredoc, which solves
> this problem by ignoring both leading spaces and leading tabs. eg.
>
> func()(
> cat <<~ EOF
> blabla
> EOF
> )
This would break backward compa
Hello.
I have a problem with indentation in bash scripts with here documents.
Normally, I use spaces for indentation, eg.
func()(
blabla
)
But if need to use here doc document in a function, I am forced to do eather
func()(
cat <<- EOF
blabla
EOF
)
or
func()(
cat << E
On Mon, Jan 04, 2021 at 10:44:40AM -0500, Saint Michael wrote:
> can you point me to your FAQ?
https://mywiki.wooledge.org/BashFAQ/045
can you point me to your FAQ?
On Mon, Jan 4, 2021 at 8:39 AM Greg Wooledge wrote:
> On Mon, Jan 04, 2021 at 08:26:59AM -0500, Saint Michael wrote:
> > In this case, how do I quickly increase the number stored in "foo"?
> > the file has 1 as content, and I have a new value to add to it
> quic
Le 04/01/2021 à 14:14, Greg Wooledge écrivait :
It should be noted that $(
var=$(ending the last line because it exactly a sub-shell shot syntax for
var=$(cat file). Sub-shell $(commands list) output is always trimmed.
--
Léa Gris
On Mon, Jan 04, 2021 at 08:26:59AM -0500, Saint Michael wrote:
> In this case, how do I quickly increase the number stored in "foo"?
> the file has 1 as content, and I have a new value to add to it quickly.
> Is there an atomic way to read,add, write a value to "foo"?
Nope!
It's almost like b
In this case, how do I quickly increase the number stored in "foo"?
the file has 1 as content, and I have a new value to add to it quickly.
Is there an atomic way to read,add, write a value to "foo"?
On Mon, Jan 4, 2021 at 8:15 AM Greg Wooledge wrote:
> On Fri, Jan 01, 2021 at 10:02:26PM +0
On Fri, Jan 01, 2021 at 10:02:26PM +0100, Ángel wrote:
> Yes. In fact, you can already do that using an interface exactly
> identical to file operations:
>
> # Store a string in shared memory with key 'foo'
> echo "Hello world" > foo
>
> # Read value of key foo
> var="$(
>
> You only need to us
On 2020-12-27 at 13:30 -0500, Saint Michael wrote:
> Yes, superglobal is great.
> Example, from the manual:
> " Shared Memory
> Shared memory allows one or more processes to communicate via memory
> that appears in all of their virtual address spaces. The pages of the
> virtual memory is referenced
I agree: python seem to be more apropriated language for complex operation.
Anyway, bash already offer a lot of features (like `coproc` and `read -t 0`)
usefull for IPC.
I wrote a little ``multiping`` bash script, as multithread demo, running many
parallels ping, reading all outputs and merging t
On 12/27/20 1:30 PM, Saint Michael wrote:
We could allow only strings or more complex objects, but using bash-language
only, an internal mechanism, and also we need to define a semaphore.
Is it doable?
Of course it's doable; all that takes is requirements, definition, and
implementation. The
On 27/12/2020 at 19:30, Saint Michael wrote:
Yes, superglobal is great.
Example, from the manual:
" Shared Memory
Shared memory allows one or more processes to communicate via memory that
appears in all of their virtual address spaces. The pages of the virtual
memory is referenced by page table e
Yes, superglobal is great.
Example, from the manual:
" Shared Memory
Shared memory allows one or more processes to communicate via memory that
appears in all of their virtual address spaces. The pages of the virtual
memory is referenced by page table entries in each of the sharing
processes' page t
On 12/27/20 12:38 PM, Saint Michael wrote:
Bash is very powerful for its ability to use all kinds of commands and pipe
information through them. But there is a single thing that is impossible to
achieve except using files on the hard drive or on /tmp. We need a new
declare -g (global) where a var
Bash is very powerful for its ability to use all kinds of commands and pipe
information through them. But there is a single thing that is impossible to
achieve except using files on the hard drive or on /tmp. We need a new
declare -g (global) where a variable would have its contents changed by
subs
On 10/28/20 10:51 AM, Dr. Werner Fink wrote:
> On 2020/10/28 10:23:57 -0400, Chet Ramey wrote:
>> On 10/16/20 9:28 AM, Chet Ramey wrote:
>>> On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
>>>
Also a warning hint in the manual page could
help users before enabling this feature :)
>>>
>>> I ag
On 2020/10/28 10:23:57 -0400, Chet Ramey wrote:
> On 10/16/20 9:28 AM, Chet Ramey wrote:
> > On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
> >
> >> Also a warning hint in the manual page could
> >> help users before enabling this feature :)
> >
> > I agree, and the manual page in the release will r
On 10/16/20 9:28 AM, Chet Ramey wrote:
> On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
>
>> Also a warning hint in the manual page could
>> help users before enabling this feature :)
>
> I agree, and the manual page in the release will reflect bracketed paste's
> default setting. However, readline
On Fri, Oct 16, 2020 at 09:28:26AM -0400, Chet Ramey wrote:
> On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
>
> > Also a warning hint in the manual page could
> > help users before enabling this feature :)
>
> I agree, and the manual page in the release will reflect bracketed paste's
> default sett
On 10/16/20 9:16 AM, Dr. Werner Fink wrote:
> Also a warning hint in the manual page could
> help users before enabling this feature :)
I agree, and the manual page in the release will reflect bracketed paste's
default setting. However, readline doesn't try to enable bracketed paste if
tcgetattr
On 2020/10/16 09:03:53 -0400, Chet Ramey wrote:
> On 10/16/20 5:41 AM, Dr. Werner Fink wrote:
> > Hi,
> >
> > after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
> > staging process. During build the package python-pexpect throws errors
> > in its test suite, e.g.
> >
> > [ 260
On 10/16/20 5:41 AM, Dr. Werner Fink wrote:
> Hi,
>
> after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
> staging process. During build the package python-pexpect throws errors
> in its test suite, e.g.
>
> [ 260s] self = testMethod=test_async_replwrap_multiline>
> [ 260s]
Hi,
after build rc1 of bash 5.1 as well as readline-8.1 I've set up test
staging process. During build the package python-pexpect throws errors
in its test suite, e.g.
[ 260s] self =
[ 260s]
[ 260s] def test_async_replwrap_multiline(self):
[ 260s] bash = replwrap.bash()
[ 260s
On 4/22/20 9:31 PM, Dale R. Worley wrote:
> The crux of the problem, IMHO, is to look at it from the right angle:
I'm not going to add this to bash.
It's a bad idea to add a feature that will perpetually require a user to
patch glibc (!), and that will never be added to any mainline glibc
distrib
On April 22, 2020 6:32:07 PM wor...@alum.mit.edu (Dale R. Worley) wrote:
The crux of the problem, IMHO, is to look at it from the right angle:
Occasionally, the user desires that I/O through certain pipes should be
unbuffered, that is, the stdio stream(s) that write into the pipe should
be unbu
On 4/23/20 4:39 PM, Dale R. Worley wrote:
Andreas Schwab writes:
See stdbuf(1).
The limitation(s) of stdbuf are: It can only be applied to the standard
I/O streams. It doesn't affect statically-linked executables. It only
applies to a single executable, so if the command is a shell functio
Andreas Schwab writes:
> See stdbuf(1).
The limitation(s) of stdbuf are: It can only be applied to the standard
I/O streams. It doesn't affect statically-linked executables. It only
applies to a single executable, so if the command is a shell function or
script, or creates subprocesses, it doe
See stdbuf(1).
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
The crux of the problem, IMHO, is to look at it from the right angle:
Occasionally, the user desires that I/O through certain pipes should be
unbuffered, that is, the stdio stream(s) that write into the pipe should
be unbuffered, rather than the default block-buffered. These are
situations where
Greg Wooledge writes:
> On Tue, Apr 21, 2020 at 08:38:41PM -0400, Dale R. Worley wrote:
>> The "unbuffered pipe" symbol ">|>" causes Bash to set in the
>> environment of the "grep" process a variable "STDOUT_UNBUFFERED" with
>> a value that contains the dev and ino values for the pipe which the
>>
On Tue, Apr 21, 2020 at 08:38:41PM -0400, Dale R. Worley wrote:
> The "unbuffered pipe" symbol ">|>" causes Bash to set in the
> environment of the "grep" process a variable "STDOUT_UNBUFFERED" with
> a value that contains the dev and ino values for the pipe which the
> "grep" process sees as fd 1.
diff --git a/libio/filedoalloc.c b/libio/filedoalloc.c
index 412b8d5937..35044e3512 100644
--- a/libio/filedoalloc.c
+++ b/libio/filedoalloc.c
@@ -58,6 +58,7 @@
#include "libioP.h"
#include
#include
+#include
#include
#include
@@ -71,6 +72,17 @@ local_isatty (int fd)
return res;
}
diff --git a/command.h b/command.h
index 3249516..ef611a4 100644
--- a/command.h
+++ b/command.h
@@ -186,6 +186,7 @@ typedef struct element {
#define CMD_COPROC_SUBSHELL 0x1000
#define CMD_LASTPIPE 0x2000
#define CMD_STDPATH0x4000 /* use standard path for command lookup
*/
+#
The baseline behavior is that this command, after 10 seconds, outputs
10 lines of output:
$ bash -c 'for I in $( seq 10 ) ; do echo ABCDE ; sleep 1 ; done | grep A | cat'
To build and run a demo of the "unbuffered pipes" feature:
Create and cd to a scratch directory.
Build a modified Bash:
$ w
It may seem intemperate to propose that a program with an 82-page
manual "page" could benefit from yet another feature, but that is what
this is doing: Bash's users would benefit from a feature that
suppresses buffering of output sent to particular pipes (designated by
the user).
At the bottom of
On Thu, Apr 16, 2015 at 9:50 AM, Greg Wooledge wrote:
> I don't see why such features should be compiled into bash's read builtin.
> I'd have no problem with adding better splitting/joining/parsing features
> in a more general context, probably operating on a string variable, but
> certainly not o
On Thu, Apr 16, 2015 at 09:39:08AM -0500, Dan Douglas wrote:
> On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge wrote:
> > On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote:
> >> I find myself in need of something along the lines of Python's
> >> `re.split` and `re.findall` all the time. E
While I was developing a small script, I thought about how to use -N flag
to a greater extent. Although -N in its own is very limited. It does serve
the purpose but not what I need. I also discussed this in #bash freenode,
and got some ideas like:
pgas: while read -n1 d;do case $d in '')brea
On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote:
> I find myself in need of something along the lines of Python's
> `re.split` and `re.findall` all the time. E.g. splitting an ip into an
> array of octets.
IFS=. read -ra octets <<< "$ip"
On Thu, Apr 16, 2015 at 9:32 AM, Greg Wooledge wrote:
> On Thu, Apr 16, 2015 at 09:29:56AM -0500, Dan Douglas wrote:
>> I find myself in need of something along the lines of Python's
>> `re.split` and `re.findall` all the time. E.g. splitting an ip into an
>> array of octets.
>
> IFS=. read -ra oc
On Thu, Apr 16, 2015 at 8:55 AM, Eduardo A. Bustamante López
wrote:
> Any reason to justify this instead of using a simple loop?
I find myself in need of something along the lines of Python's
`re.split` and `re.findall` all the time. E.g. splitting an ip into an
array of octets.
On Thu, Apr 16,
Any reason to justify this instead of using a simple loop?
--
Eduardo Bustamante
https://dualbus.me/
Hi,
According to ''help read'' we can specify -N[chars] to trigger return
automatically. Is it possible to approach read differently?
For example: $re is some regular expression
read -N$re -p "Enter two or three digits to continue " getInput
The above is much of a pseudo-code but I hope you
> what about something like
>
> function __bash_completion_loader() {
> source "/etc/bash_completion.d/$1.sh" &>/dev/null
> return 127
> }
> complete -F __bash_completion_loader ''
>
> which will catch all programmable completions? Need change in bash.
> More info at https://bugzilla.redhat.c
Hi,
what about something like
function __bash_completion_loader() {
source "/etc/bash_completion.d/$1.sh" &>/dev/null
return 127
}
complete -F __bash_completion_loader ''
which will catch all programmable completions? Need change in bash.
More info at https://bugzilla.redhat.com/show_bug.cgi?i
64 matches
Mail list logo
