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
30 matches
Mail list logo
