On Thu, Oct 03, 2024 at 03:19:09PM +0300, Anssi Saari wrote:
> writes:
>
> > What actually happens seems completely different to me: the shell
> > gets the EPIPE from the dying tee before it can see the EINTR, right?
>
> That depends. tee -i will ignore SIGINT but ./script gets it. So it can
> k
writes:
> What actually happens seems completely different to me: the shell
> gets the EPIPE from the dying tee before it can see the EINTR, right?
That depends. tee -i will ignore SIGINT but ./script gets it. So it can
keep writing in the pipe, from the script proper or its SIGINT handler
and e
Greg Wooledge (12024-10-02):
> In that case, there are THREE foreground processes which receive a SIGINT:
>
> * The interactive shell, which ignores it, because interactive shells
>always ignore SIGINT.
You are very right on the rest, but this is a mistake: the interactive
shell is not in th
On Wed, Oct 02, 2024 at 08:17:34AM -0400, Greg Wooledge wrote:
[...]
Thanks for your (as always) very exhaustive description.
> What I'm mostly trying to convey here, though, is that signals do not
> *propagate* from one process to another in any kind of automatic way.
That's more or less what
ich ignores it, because interactive shells
always ignore SIGINT.
* The ./script process, which is presumably expanded to "/bin/bash ./script".
* The tee -i log process.
We know the interactive shell ignores it, and we can reasonably assume
that the tee will accept it and terminate.
On Wed, Oct 02, 2024 at 02:43:11PM +0300, Anssi Saari wrote:
> writes:
[...]
> > Explain to us what you really mean by "signals pass up the pipe", then
> > things
> > might become clearer.
>
> I realize I didn't spell it out. It's the, to me, obvious solution to
> Tim's problem, as he wrote:
>
writes:
> On Tue, Oct 01, 2024 at 01:53:26PM +0300, Anssi Saari wrote:
>> Greg Wooledge writes:
>>
>> > On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
>> >> Tim Woodall writes:
>> >>
>> >> > However on trying to debug something else, I wanted to run it like this:
>> >> >
>> >> > .
On Tue, Oct 01, 2024 at 01:53:26PM +0300, Anssi Saari wrote:
> Greg Wooledge writes:
>
> > On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
> >> Tim Woodall writes:
> >>
> >> > However on trying to debug something else, I wanted to run it like this:
> >> >
> >> > ./script |& tee log
>
Greg Wooledge writes:
> On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
>> Tim Woodall writes:
>>
>> > However on trying to debug something else, I wanted to run it like this:
>> >
>> > ./script |& tee log
>> >
>> > and now it doesn't clean up if I it.
>>
>> Just a point here about
ing?
In this particular case it's almost certain that the tee program will
have gone away before the bash script calls the exit handler.
That last sentence seems _very_ relevant here.
If the other end of the pipe is gone, then the shell builtin `echo`
probably fails with SIGPIPE/EPIPE. So will
On Mon, Sep 30, 2024 at 14:08:19 +0300, Anssi Saari wrote:
> Tim Woodall writes:
>
> > However on trying to debug something else, I wanted to run it like this:
> >
> > ./script |& tee log
> >
> > and now it doesn't clean up if I it.
>
> Just a point here about tee since I didn't see anyone else
Tim Woodall writes:
> However on trying to debug something else, I wanted to run it like this:
>
> ./script |& tee log
>
> and now it doesn't clean up if I it.
Just a point here about tee since I didn't see anyone else mention
it. tee has had the -i option to ignore interrupt signals for ages.
g?
>
> In this particular case it's almost certain that the tee program will
> have gone away before the bash script calls the exit handler.
That last sentence seems _very_ relevant here.
If the other end of the pipe is gone, then the shell builtin `echo`
probably fails with SIGPIPE
aborted!)
I still can't create a small testcase but maybe this gives someone a
clue what issue I'm hitting?
In this particular case it's almost certain that the tee program will
have gone away before the bash script calls the exit handler.
apt-cache policy bash
bash:
Installed: 5.2.15-2+b7
On Sat, Sep 28, 2024 at 15:17:47 +0100, Alain D D Williams wrote:
> On Sat, Sep 28, 2024 at 10:13:59AM -0400, Greg Wooledge wrote:
> > On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
> > > Is there a way in bash to guarantee that a trap gets called for cleanup
> > > in a script?
> >
> >
On Sat, Sep 28, 2024 at 10:13:59AM -0400, Greg Wooledge wrote:
> On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
> > Is there a way in bash to guarantee that a trap gets called for cleanup
> > in a script?
>
> #!/bin/bash
> trap cleanup EXIT
> cleanup() {
> ...
> }
>
> This works i
On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote:
> Is there a way in bash to guarantee that a trap gets called for cleanup
> in a script?
#!/bin/bash
trap cleanup EXIT
cleanup() {
...
}
This works in bash -- i.e., it calls the cleanup function regardless
of whether the shell exits b
On 9/28/24 15:53, Tim Woodall wrote:
Is there a way in bash to guarantee that a trap gets called for cleanup
in a script?
I have a script that works perfectly normally and cleans up after
itself, even if it goes wrong.
However on trying to debug something else, I wanted to run it like this:
./
Is there a way in bash to guarantee that a trap gets called for cleanup
in a script?
I have a script that works perfectly normally and cleans up after
itself, even if it goes wrong.
However on trying to debug something else, I wanted to run it like this:
./script |& tee log
and now it doesn't
On Sun, Mar 5, 2023 at 07:20 Nicolas George wrote:
...
> Tom Browder (12023-03-05):
> > Yes, but please use its new name, Raku. Note new releases come out
> monthly
> so you shouldn't use the Debian packages since they are way behind. We
> have
I shouldn't have said "you shouldn't use the Debi
On Sun 05 Mar 2023 at 16:30:10 (-0500), Greg Wooledge wrote:
> On Sun, Mar 05, 2023 at 02:37:48PM -0600, David Wright wrote:
> > There are many lists of dangerous aliases on the web, but I haven't
> > found a list of such aliases that can't be transcribed into functions.
>
> Here's one document:
>
Le 3/4/23 à 09:22, Ken Young a écrit :
Hello,
Hi Ken!
3) the content of bash script
$ cat get.sh
#!/bin/bash
source ~/.bash_profile
k get node
4) alias can't work
$ ./get.sh
./get.sh: line 5: k: command not found
Two options :
1. either use #!/bin/bash -i as your shebang.
On Sun, Mar 05, 2023 at 02:37:48PM -0600, David Wright wrote:
> There are many lists of dangerous aliases on the web, but I haven't
> found a list of such aliases that can't be transcribed into functions.
Here's one document:
https://www.chiark.greenend.org.uk/~sgtatham/aliases.html
On Sat 04 Mar 2023 at 12:23:58 (-0500), Greg Wooledge wrote:
> On Sat, Mar 04, 2023 at 11:14:39AM -0600, David Wright wrote:
> > > This use is discouraged
> >
> > There's a place for warning about the use of aliases in, say,
> > Greg's BashPitfalls, or books, but not here.
>
> Discouraging th
On Sun, Mar 05, 2023 at 02:19:38PM +0100, Nicolas George wrote:
> Tom Browder (12023-03-05):
> > Yes, but please use its new name, Raku. Note new releases come out monthly
> > so you shouldn't use the Debian packages since they are way behind. We have
> > a member on the release team who provides D
Tom Browder (12023-03-05):
> Yes, but please use its new name, Raku. Note new releases come out monthly
> so you shouldn't use the Debian packages since they are way behind. We have
> a member on the release team who provides Debian packages as "rakudo-pkg"
> so apt/aptitude update/upgrade work as
On Sun, Mar 05, 2023 at 07:30:18PM +0800, Ken Young wrote:
> Is perl6 production ready?
Of course. But be aware that it is quite a different language.
> I have not used perl for a long time.
If you prefer the "old" Perl (I do, for... reasons), it's still
being maintained actively, too.
Cheers
-
On Sun, Mar 5, 2023 at 05:30 Ken Young wrote:
> Is perl6 production ready?
>
Yes, but please use its new name, Raku. Note new releases come out monthly
so you shouldn't use the Debian packages since they are way behind. We have
a member on the release team who provides Debian packages as "rakudo
Is perl6 production ready?
I have not used perl for a long time.
Sincerely,
Ken Young
On Sun, Mar 5, 2023 at 7:28 PM Tom Browder wrote:
> My take:
>
> I use aliases heavily in my shell (bash), but I rarely use bash scripting
> at all.
>
> For any serious scripting, since about 2016 I'ved used
My take:
I use aliases heavily in my shell (bash), but I rarely use bash scripting
at all.
For any serious scripting, since about 2016 I'ved used Raku (formerly Perl
6). Before that I used Perl. Both are much easier to use.
-Tom
; root@nxacloud-bloghost:~# echo $SHELL
>
> /bin/bash
Both statements are correct, within their contexts.
The default *interactive* shell for user accounts is /bin/bash.
The default /bin/sh symlink (for scripts using #!/bin/sh, etc.) is dash.
The author of a script chooses whether the sheba
On Sat, Mar 4, 2023 at 5:53 PM David wrote:
> On Sat, 4 Mar 2023 at 19:30, Ken Young wrote:
>
> > Do you know why my alias can't work in the bash script?
> > The info is as follows.
> >
> > 1) this alias does exist
> > $ alias |grep 'k='
&
On Sat, Mar 04, 2023 at 11:14:39AM -0600, David Wright wrote:
> > This use is discouraged
>
> There's a place for warning about the use of aliases in, say,
> Greg's BashPitfalls, or books, but not here.
Discouraging the use of legacy features that are considered dangerous
in modern usage is f
On Sat 04 Mar 2023 at 20:52:15 (+1100), David wrote:
> Hi. Friends don't help friends to do bad things :)
>
> Debian's default shell is 'dash'. Its manual, readable using 'man dash',
> says
>
> Aliases provide a convenient way for naive users to create shorthands
> for commands without h
oing will advise.
Do you mean this:
For almost every purpose, aliases are superseded by shell functions.
Your statements are so incredibly vague that I can't tell what you're
trying to say.
In any case, the Subject: header still says "bash script", and in bash
scripts, al
On Sun, 5 Mar 2023 at 00:12, Tom Furie wrote:
> On Sat, Mar 04, 2023 at 08:52:15PM +1100, David wrote:
> > Debian's default shell is 'dash'. Its manual, readable using 'man dash',
> > says
>
> The script explicitly calls bash. The rest of your point is still
> (coincidentally) valid though, as it
On Sat, Mar 04, 2023 at 08:52:15PM +1100, David wrote:
> Debian's default shell is 'dash'. Its manual, readable using 'man dash',
> says
The script explicitly calls bash. The rest of your point is still
(coincidentally) valid though, as it would be in most of the popular shells
as far as I'm aware
On Sat, 4 Mar 2023 at 19:30, Ken Young wrote:
> Do you know why my alias can't work in the bash script?
> The info is as follows.
>
> 1) this alias does exist
> $ alias |grep 'k='
> alias k='minikube kubectl --'
>
> 2) it also exists in .bash_pro
On Sat, Mar 04, 2023 at 10:23:24AM +0100, Kamil Jońca wrote:
> Ken Young writes:
> [..]
>
> I am not bash expert (prefer zsh) but as far as I know they are
> expadnded during interactive session only, not in scripts.
That's at least what the man page says (man bash(1)):
ALIASES
Aliases allo
Ken Young writes:
[..]
I am not bash expert (prefer zsh) but as far as I know they are
expadnded during interactive session only, not in scripts.
>
> $ ./get.sh
>
> ./get.sh: line 5: k: command not found
>
https://www.gnu.org/software/bash/manual/bash.html#Aliases
--8<---cut here-
Hello,
Do you know why my alias can't work in the bash script?
The info is as follows.
1) this alias does exist
$ alias |grep 'k='
alias k='minikube kubectl --'
2) it also exists in .bash_profile
$ cat ~/.bash_profile |grep 'k='
alias k="minik
On 5/21/2022 3:55 PM, Greg Wooledge wrote:
On Sat, May 21, 2022 at 10:08:42AM +0100, Morgan Read wrote:
I've come up with:
`cd ~/Maildir/new/; for f in *; do mv -- "$f" ~/Maildir/cur/"${f%}.eml"; cd
-; done`
You aren't checking whether the first cd succeeds. If it fails for any
reason, you're
Greg Wooledge wrote:
> On Sat, May 21, 2022 at 10:08:42AM +0100, Morgan Read wrote:
> > I've come up with:
> > `cd ~/Maildir/new/; for f in *; do mv -- "$f" ~/Maildir/cur/"${f%}.eml"; cd
> > -; done`
>
> You aren't checking whether the first cd succeeds. If it fails for any
> reason, you're goin
On Sat, May 21, 2022 at 10:08:42AM +0100, Morgan Read wrote:
> I've come up with:
> `cd ~/Maildir/new/; for f in *; do mv -- "$f" ~/Maildir/cur/"${f%}.eml"; cd
> -; done`
You aren't checking whether the first cd succeeds. If it fails for any
reason, you're going to end up moving file(s) out of wh
> unicorn:~$ mkdir /tmp/x && cd "$_"
> unicorn:/tmp/x$ mkdir 98 99 100 101 102 103 104
> unicorn:/tmp/x$ echo *
> 100 101 102 103 104 98 99
Hello Gred
Very thanks. Worked :)
Best regards...
On Tue, Oct 12, 2021 at 7:04 PM Greg Wooledge wrote:
>
> On Tue, Oct 12, 2021 at 05:41:59PM +0300, Goka
On Tue, Oct 12, 2021 at 05:41:59PM +0300, Gokan Atmaca wrote:
> I have directories created at different times. This last updated
> directory is in the directory with a symbolic link named "last".
> Directories are named from 100 to 110. what i want is to delete all
> directories except the folder n
On Tue 12 Oct 2021 at 17:41:59 (+0300), Gokan Atmaca wrote:
>
> I have directories created at different times. This last updated
> directory is in the directory with a symbolic link named "last".
> Directories are named from 100 to 110. what i want is to delete all
> directories except the folder
Hello
I have directories created at different times. This last updated
directory is in the directory with a symbolic link named "last".
Directories are named from 100 to 110. what i want is to delete all
directories except the folder named "last" and 4 before it. How can I
do that?
Exampe_folder_
On Fri, Aug 06, 2021 at 07:52:20AM -0700, Gary L. Roach wrote:
>
> On 8/5/21 1:15 PM, Greg Wooledge wrote:
[...]
> >>You're doing *way* too much work. It's a gigantic X-Y problem.
> I agree. I'm going back through the code and rewriting most of it.
OTOH... this is how most learning journeys st
On 8/5/21 1:15 PM, Greg Wooledge wrote:
On Thu, Aug 05, 2021 at 01:03:16PM -0700, Gary L. Roach wrote:
First, the IFS command sets the string separator. The default values are
space /n and one other. The / is not among them.
Yes, we know that. The issue is that you are setting IFS for the
wh
On 06/08/2021 00:30, David wrote:
> On Fri, 6 Aug 2021 at 06:03, Gary L. Roach wrote:
>
>> Second, why am I separating out the Path the way I am doing? I need to
>> check each level for existence then, if the level doesn't exist, create
>> the directory, cd to the directory, set chown and -x chmo
On Fri, Aug 06, 2021 at 10:52:51AM +1000, David wrote:
[...]
> I was commenting on how I have always been puzzled why
> someone made the effort to give 'chmod' an '-R' option, but
> never made it actually useful for common cases. As it is,
> it seems that it's really only useful for modifying the
On Fri, 6 Aug 2021 at 13:06, David Wright wrote:
> On Fri 06 Aug 2021 at 09:30:17 (+1000), David wrote:
> > 'chmod -R' is less useful because it does not discriminate
> > between files and directories, I never understood why it
> > does not offer that option, because usually we need all file
> >
On Fri 06 Aug 2021 at 09:30:17 (+1000), David wrote:
> On Fri, 6 Aug 2021 at 06:03, Gary L. Roach wrote:
>
> > Second, why am I separating out the Path the way I am doing? I need to
> > check each level for existence then, if the level doesn't exist, create
> > the directory, cd to the directory,
On Thu, Aug 05, 2021 at 09:47:04PM -0400, The Wanderer wrote:
> I believe I've hit contexts in which I could use '-print0 | xargs -0'
> but couldn't figure out a way to get the job done with '-exec', because
> I needed the command which was being run to process the output to be a
> pipeline. (I no
On 2021-08-05 at 20:25, Greg Wooledge wrote:
>> >> find . -type d -exec chmod -v 0644 '{}' \;
>
>> > Use + instead of \; to make them more efficient.
>
>> What does + make as a difference ?
>
> It's a replacement for xargs, except that it actually works, unlike
> xargs, which is horribly broken
On Fri, 6 Aug 2021 at 10:58, Christian Groessler wrote:
> On 8/6/21 2:52 AM, David wrote:
> > I was commenting on how I have always been puzzled why
> > someone made the effort to give 'chmod' an '-R' option, but
> > never made it actually useful for common cases. As it is,
> > it seems that it's
On Fri, Aug 06, 2021 at 02:58:00AM +0200, Christian Groessler wrote:
> On 8/6/21 2:52 AM, David wrote:
> > I was commenting on how I have always been puzzled why
> > someone made the effort to give 'chmod' an '-R' option, but
> > never made it actually useful for common cases. As it is,
> > it seem
On 8/6/21 2:52 AM, David wrote:
I was commenting on how I have always been puzzled why
someone made the effort to give 'chmod' an '-R' option, but
never made it actually useful for common cases. As it is,
it seems that it's really only useful for modifying the write attribute.
Hmm. "chmod -R go
On Fri, 6 Aug 2021 at 10:01, Polyna-Maude Racicot-Summerside
wrote:
> On 2021-08-05 7:30 p.m., David wrote:
> > On Fri, 6 Aug 2021 at 06:03, Gary L. Roach wrote:
> > 'chmod -R' is less useful because it does not discriminate
> > between files and directories, I never understood why it
> > does n
On 8/6/21 2:01 AM, Polyna-Maude Racicot-Summerside wrote:
find . -type d -exec chmod -v 0644 '{}' \;
to change the folder
find . -type f -exec chmod -v 0755 '{}' \;
to change files
Pah. Use 'xargs' :-)
$ find . -type f -print0 | xargs -0 chmod 644
$ find . -type d -print0 | xargs -0 chmod
> >> find . -type d -exec chmod -v 0644 '{}' \;
> > Use + instead of \; to make them more efficient.
> What does + make as a difference ?
It's a replacement for xargs, except that it actually works, unlike
xargs, which is horribly broken without GNU extensions.
find . -type d -exec chmod 755 {}
Hi,
On 2021-08-05 8:07 p.m., Greg Wooledge wrote:
> On Thu, Aug 05, 2021 at 08:01:22PM -0400, Polyna-Maude Racicot-Summerside
> wrote:
>> find . -type d -exec chmod -v 0644 '{}' \;
>>
>> to change the folder
>>
>> find . -type f -exec chmod -v 0755 '{}' \;
>>
>> to change files
>
> You've switch
On Thu, Aug 05, 2021 at 08:01:22PM -0400, Polyna-Maude Racicot-Summerside wrote:
> find . -type d -exec chmod -v 0644 '{}' \;
>
> to change the folder
>
> find . -type f -exec chmod -v 0755 '{}' \;
>
> to change files
You've switched the permissions around. You want 644 on the files, and
755 o
Hi,
On 2021-08-05 7:30 p.m., David wrote:
> On Fri, 6 Aug 2021 at 06:03, Gary L. Roach wrote:
>
>> Second, why am I separating out the Path the way I am doing? I need to
>> check each level for existence then, if the level doesn't exist, create
>> the directory, cd to the directory, set chown an
On Fri, 6 Aug 2021 at 06:03, Gary L. Roach wrote:
> Second, why am I separating out the Path the way I am doing? I need to
> check each level for existence then, if the level doesn't exist, create
> the directory, cd to the directory, set chown and -x chmod. After that
> check the next level and
On Wed, Aug 4, 2021 at 18:58 Gary L. Roach wrote:
> Hi all;
> I have just recently delved into the magical world of Bash scripting and
I long ago gave up bash scripting for other than simple scripts, even for
sysadmin chores.
Most Linux distros, including our favorite Debian, come with Perl in
On Thu, Aug 05, 2021 at 01:03:16PM -0700, Gary L. Roach wrote:
> First, the IFS command sets the string separator. The default values are
> space /n and one other. The / is not among them.
Yes, we know that. The issue is that you are setting IFS for the
whole script, when you probably *should* be
hi all;
I really appreciate all of your help. The file now works. See attached.
Now t0 answer some questions.
First, the IFS command sets the string separator. The default values are
space /n and one other. The / is not among them. If I don't set the
delimiter before I do the read, the whol
On Thu, Aug 05, 2021 at 08:32:39AM -0400, Greg Wooledge wrote:
> On Thu, Aug 05, 2021 at 01:59:06PM +0200, to...@tuxteam.de wrote:
> > On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> > > The external versions of test and [ need to exist for POSIX conformance,
> > > and also so that
On Thu, Aug 05, 2021 at 01:59:06PM +0200, to...@tuxteam.de wrote:
> On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> > The external versions of test and [ need to exist for POSIX conformance,
> > and also so that you can -exec them from find(1) or other similar
> > programs.
>
> I
On Wed, Aug 04, 2021 at 08:47:30PM -0700, Gary L. Roach wrote:
> Thanks for the help but I still have the problem of the if statement always
> being true. This time I enclosed the file so you can test it.
You didn't make the changes that I told you to make yesterday. But
this has already been cov
On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> On Thu, Aug 05, 2021 at 10:07:12AM +0200, to...@tuxteam.de wrote:
> > [1] Nowadays this is a little white lie: most shells have them
> >as builtins, but they are supposed to behave like regular
> >programs, for compat. There /
On Thu, Aug 05, 2021 at 10:38:47AM +0200, to...@tuxteam.de wrote:
> On Thu, Aug 05, 2021 at 09:26:35AM +0100, Tixy wrote:
> > ; has no special meaning inside "". The expression is true because
> > there is only a single non-null argument between the [ ]
Precisely. But you're probably not explaini
On Thu, Aug 05, 2021 at 10:07:12AM +0200, to...@tuxteam.de wrote:
> [1] Nowadays this is a little white lie: most shells have them
>as builtins, but they are supposed to behave like regular
>programs, for compat. There /is/ a /bin/test, but I can't
>find a /bin/[ on my system anymore.
On Thu, Aug 05, 2021 at 09:26:35AM +0100, Tixy wrote:
> On Thu, 2021-08-05 at 10:36 +0300, Anssi Saari wrote:
> [...]
> >
> > [ A="0 ; " ]
> >
> > is always true. It seems it probably has something to do with expansion,
> > quoting and the special meaning of ;.
> >
>
> ; has no special meaning
On Thu, 2021-08-05 at 10:36 +0300, Anssi Saari wrote:
[...]
>
> [ A="0 ; " ]
>
> is always true. It seems it probably has something to do with expansion,
> quoting and the special meaning of ;.
>
; has no special meaning inside "". The expression is true because
there is only a single non-null
On Wed, Aug 04, 2021 at 08:47:30PM -0700, Gary L. Roach wrote:
> Thanks for the help but I still have the problem of the if statement
> always being true. This time I enclosed the file so you can test it.
Please, don't top quote. It confuses the hell out of me.
Now, I think in your script
if t
send back an Awk or Sed statement that is more efficient. I am
> having enough trouble with the Bash script.
Well, are trying to check the existence of each part of each path
element? So for example, first check /Test exists, then /Test/gary,
then /Test/gary/run and so on? Because just checking the
On 8/5/2021 5:47 AM, Gary L. Roach wrote:
Thanks for the help but I still have the problem of the if statement
always being true. This time I enclosed the file so you can test it.
Two things:
- Why is the var 'IFS' set above the read command?
- What are you trying to do here?
--
John Doe
Thanks for the help but I still have the problem of the if statement
always being true. This time I enclosed the file so you can test it.
Gary R
On 8/4/21 5:04 PM, Greg Wooledge wrote:
On Wed, Aug 04, 2021 at 04:58:00PM -0700, Gary L. Roach wrote:
Path="/Test/gary/run/something"
IFS=/
read -a
On Wed, Aug 04, 2021 at 04:58:00PM -0700, Gary L. Roach wrote:
> Path="/Test/gary/run/something"
> IFS=/
> read -a Array <<< $Path
You're setting IFS permanently for the whole script. It's usually better
to set it only for the duration of the single read command which uses
it. Also, read should
aving
enough trouble with the Bash script.
Something is wrong with the logic of the if-fi statement. It is
triggered every time through the loop. The statement A="0; " seems to
be true no matter what the value of A. The if statement is there to
clear out the first item in the array t
On Tue 03 Sep 2019 at 14:20:11 (-0400), Greg Wooledge wrote:
> On Tue, Sep 03, 2019 at 01:07:08PM -0500, David Wright wrote:
> > Trap is designed to break the sequential flow of commands.
> > I can't see any reason to do that when the OP wants the
> > sequence:
> >
> > execute a script
> >
On Tue, Sep 03, 2019 at 01:07:08PM -0500, David Wright wrote:
> Trap is designed to break the sequential flow of commands.
> I can't see any reason to do that when the OP wants the
> sequence:
>
> execute a script
> print a string
Are you actually able to discern the OP's desires? I can'
On Tue 03 Sep 2019 at 15:07:43 (+), Larry Dighera wrote:
> On Mon, 02 Sep 2019 08:48:50 +0200, Computer Planet
>
> wrote:
>
> >Is It possible to print of a string at the exit of a bash script?
>
> Have a look at `man bash` and search for 'trap.'
Trap i
On Mon, 02 Sep 2019 08:48:50 +0200, Computer Planet
wrote:
>Is It possible to print of a string at the exit of a bash script?
Have a look at `man bash` and search for 'trap.'
trap [-lp] [[arg] sigspec ...]
The command arg is to be read and executed when the
s
st your wishes). We don't read minds.
> Now, I ask the question in other terms:
> Is It possible to print of a string at the exit of a bash script?
> e.g.: user@mypc: # bash script has just finished! [prompt]
> with the prompt that remains immediately after the string printed.
>
On Mon, Sep 02, 2019 at 09:30:44AM +0200, Thomas Schmitt wrote:
> Hi,
>
> Computer Planet wrote:
> > Is It possible to print of a string at the exit of a bash script?
> > e.g.: user@mypc: # bash script has just finished! [prompt]
> > with the prompt that remains i
Hi,
Computer Planet wrote:
> Is It possible to print of a string at the exit of a bash script?
> e.g.: user@mypc: # bash script has just finished! [prompt]
> with the prompt that remains immediately after the string printed.
Do you mean something like this ?
$ echo -n 'use
On Mon, Sep 02, 2019 at 08:48:50AM +0200, Computer Planet wrote:
> Thanks guys,
> but this is not the solution I'm looking for ...
> Now, I ask the question in other terms:
> Is It possible to print of a string at the exit of a bash script?
Hm. You mean
echo
Still a bit con
Thanks guys,
but this is not the solution I'm looking for ...
Now, I ask the question in other terms:
Is It possible to print of a string at the exit of a bash script?
e.g.: user@mypc: # bash script has just finished! [prompt]
with the prompt that remains immediately after the string pr
On Sun, Sep 01, 2019 at 03:22:32PM -0400, Lee wrote:
[...]
> You have to source the script instead of running it.
Yes, exactly.
> I'm not entirely clear about a new shell gets it's own env that
> disappears when the shell exits thing, but try this:
It's not only a shell thing. It's a basic Uni
On 9/1/19, Computer Planet wrote:
> Hi guys!
> I'm trying, trying and trying but...
>
> How I Can put in hte end of a bash script this command:
> PS1="\[\e]0;\u@\h:
> \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w
>
On Sun 01 Sep 2019 at 17:53:51 (+0200), Computer Planet wrote:
> Hi guys!
> I'm trying, trying and trying but...
>
> How I Can put in hte end of a bash script this command:
> PS1="\[\e]0;\u@\h:
> \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[
Hi guys!
I'm trying, trying and trying but...
How I Can put in hte end of a bash script this command:
PS1="\[\e]0;\u@\h:
\w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w
#\[\033[91m\] "
so that after finishing the script the prompt wi
On Tue, 13 Aug 2019 at 05:04, Lee wrote:
> On 8/12/19, Greg Wooledge wrote:
> > On Mon, Aug 12, 2019 at 01:56:46PM -0400, Lee wrote:
>> What's the difference between ${d} and "${d}"? Or is that a bashism
>> also? (all my scripts use /bin/sh so I'm pretty clueless wrt bash)
> >
> > For more deta
On 8/12/19, Greg Wooledge wrote:
> On Mon, Aug 12, 2019 at 01:56:46PM -0400, Lee wrote:
>> What's the difference between ${d} and "${d}"? Or is that a bashism
>> also? (all my scripts use /bin/sh so I'm pretty clueless wrt bash)
>
> This applies to both sh and bash.
>
> An unquoted substitution,
On Mon, Aug 12, 2019 at 01:56:46PM -0400, Lee wrote:
> What's the difference between ${d} and "${d}"? Or is that a bashism
> also? (all my scripts use /bin/sh so I'm pretty clueless wrt bash)
This applies to both sh and bash.
An unquoted substitution, like $d or ${d}, undergoes several steps. T
1 - 100 of 529 matches
Mail list logo
