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
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
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
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
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
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
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
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
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
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
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
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
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
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
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*
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
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
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
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
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
"Gary L. Roach" writes:
> Hi all;
>
> I have just recently delved into the magical world of Bash scripting
> and programmed up the following script(not finished). The object is to
> parse the Path and check for the existence of each directory. Please
> don't send back an Awk or Sed statement
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
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
Hi all;
I have just recently delved into the magical world of Bash scripting and
programmed up the following script(not finished). The object is to parse
the Path and check for the existence of each directory. Please don't
send back an Awk or Sed statement that is more efficient. I am having
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
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.
On 8/12/19, Greg Wooledge wrote:
> On Mon, Aug 12, 2019 at 01:37:16PM -0400, Lee wrote:
>> On 8/12/19, Greg Wooledge wrote:
>> > On Mon, Aug 12, 2019 at 01:19:45PM -0400, Lee wrote:
>> >> On 8/12/19, Greg Wooledge wrote:
>> >> > P.S. it would also have been possible to work around the carriage
On Mon, Aug 12, 2019 at 01:37:16PM -0400, Lee wrote:
> On 8/12/19, Greg Wooledge wrote:
> > On Mon, Aug 12, 2019 at 01:19:45PM -0400, Lee wrote:
> >> On 8/12/19, Greg Wooledge wrote:
> >> > P.S. it would also have been possible to work around the carriage
> >> > return
> >> > issues with IFS,
On 8/12/19, Greg Wooledge wrote:
> On Mon, Aug 12, 2019 at 01:19:45PM -0400, Lee wrote:
>> On 8/12/19, Greg Wooledge wrote:
>> > P.S. it would also have been possible to work around the carriage
>> > return
>> > issues with IFS, but your dos2unix approach is perfectly valid as well.
>>
>> Just
On Mon, Aug 12, 2019 at 01:19:45PM -0400, Lee wrote:
> On 8/12/19, Greg Wooledge wrote:
> > P.S. it would also have been possible to work around the carriage return
> > issues with IFS, but your dos2unix approach is perfectly valid as well.
>
> Just out of curiosity - how?
while IFS=$' \t\r\n'
On 8/12/19, Greg Wooledge wrote:
> On Sun, Aug 11, 2019 at 02:10:06PM -0400, Stephen P. Molnar wrote:
>> Thanks to all that shared their expertise.
>>
>> #!/bin/bash
>> while IFS= read -r d
>> do
>> cd "${d}_apo-3k9b"
>> echo "${d}_apo-3k9b"
>> echo "${d}_apo-3k9b.dpf"
>>
On 08/12/2019 09:39 AM, Greg Wooledge wrote:
On Sun, Aug 11, 2019 at 02:10:06PM -0400, Stephen P. Molnar wrote:
Thanks to all that shared their expertise.
#!/bin/bash
while IFS= read -r d
do
cd "${d}_apo-3k9b"
echo "${d}_apo-3k9b"
echo "${d}_apo-3k9b.dpf"
On Sun, Aug 11, 2019 at 02:10:06PM -0400, Stephen P. Molnar wrote:
> Thanks to all that shared their expertise.
>
> #!/bin/bash
> while IFS= read -r d
> do
> cd "${d}_apo-3k9b"
> echo "${d}_apo-3k9b"
> echo "${d}_apo-3k9b.dpf"
> /home/comp/Apps/Autodock/autodock4 -p
On 08/11/2019 11:56 AM, Lee wrote:
On 8/11/19, David wrote:
On Mon, 12 Aug 2019 at 01:07, Stephen P. Molnar
wrote:
Thanks for the suggestion.
However,
comp@AbNormal:~/Apps/Models/1-PhosphorusLigands/Acetylcholinesterases/3K9B/Results$
./Run.ligand.list.sh
./Run.ligand.list.sh: line 4:
On 8/11/19, David wrote:
> On Mon, 12 Aug 2019 at 01:07, Stephen P. Molnar
> wrote:
>>
>> Thanks for the suggestion.
>> However,
>> comp@AbNormal:~/Apps/Models/1-PhosphorusLigands/Acetylcholinesterases/3K9B/Results$
>> ./Run.ligand.list.sh
>> ./Run.ligand.list.sh: line 4: cd:
On Mon, 12 Aug 2019 at 01:07, Stephen P. Molnar wrote:
>
> Thanks for the suggestion.
> However,
> comp@AbNormal:~/Apps/Models/1-PhosphorusLigands/Acetylcholinesterases/3K9B/Results$
> ./Run.ligand.list.sh
> ./Run.ligand.list.sh: line 4: cd: $'Acetylcholine\r_apo-3k9b': No such
> file or
On 08/11/2019 10:39 AM, David wrote:
On Sun, 11 Aug 2019 at 23:18, Stephen P. Molnar wrote:
I am running an up-to-date installation of Buster on my Linux platform
and have run into a strange problem with a bash script.
[...]
for d in $(cat ligand.list)
This line is the problem, it is
On Sun, 11 Aug 2019 at 23:18, Stephen P. Molnar wrote:
>
> I am running an up-to-date installation of Buster on my Linux platform
> and have run into a strange problem with a bash script.
[...]
> for d in $(cat ligand.list)
This line is the problem, it is vulnerable to various kinds
of
On Sun, Aug 11, 2019 at 09:17:53AM -0400, Stephen P. Molnar wrote:
> I am running an up-to-date installation of Buster on my Linux
> platform and have run into a strange problem with a bash script.
>
> I have a number of ligand protein docking applications which involve
> ligand sets docking on a
I am running an up-to-date installation of Buster on my Linux platform
and have run into a strange problem with a bash script.
I have a number of ligand protein docking applications which involve
ligand sets docking on a protein and am using Autodock with the the
Racoon file editor
Chris Davies chris-use...@roaima.co.uk writes:
Cam Hutchison c...@xdna.net wrote:
BK_LIST=()
Append to the array with +=
BK_LIST+=${PARAM}
This += syntax appears not to work with my version of bash
(4.1.5(1)-release from package bash 4.1-3). Instead I have
to do this:
BK_LIST+=(${PARAM})
Cam Hutchison c...@xdna.net wrote:
Sigh. Sorry, it was a typo. That explains why it did not work for the OP.
Phew!
These array things are new to me in a shell context - I've used
associative and indexed arrays for years in awk and perl, though - and
after your example didn't work I went digging
Cam Hutchison c...@xdna.net wrote:
BK_LIST=()
Append to the array with +=
BK_LIST+=${PARAM}
This += syntax appears not to work with my version of bash
(4.1.5(1)-release from package bash 4.1-3). Instead I have
to do this:
BK_LIST+=(${PARAM})
Was yours a typo, or is it something that now
When dealing with paths in bash i usually employ two things:
One is declaring arrays like this:
FILES_LIST=( )
And everytime I want to append to the array I go like this:
FILES_LIST=( ${FILES_LIST[@]} ${NEW_FILE} )
Obviously I will have problems if the paths or files have spaces in
their
Iuri Guilherme dos Santos Martins wrote:
When dealing with paths in bash i usually employ two things:
One is declaring arrays like this:
FILES_LIST=( )
And everytime I want to append to the array I go like this:
FILES_LIST=( ${FILES_LIST[@]} ${NEW_FILE} )
Obviously I will have problems if
Soare Catalin lolinux.so...@gmail.com writes:
Thank you everyone for replying, but unfortunately, nothing seems to work
for the moment, although all the answers appear to make sense.
First, the array solution appears to work, but when tar gets all the
parameters, they become a long string without
I wrote:
...
FILES_LIST=( ${FILES_LIST[@]} ${NEW_FILE} )
You can also write:
FILE_LIST[${#FILE_LIST[@]}]=${NEW_FILE}
Daniel
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Soare Catalin lolinux.so...@gmail.com writes:
The script will take files or dirs as parameters and will back them up in a
presefined location, using tar. Problems arise when it will encounter files
or directories which contain spaces in their names.
then #is it an existing directory?
On 22/04/12 08:34, Cam Hutchison wrote:
Soare Catalinlolinux.so...@gmail.com writes:
The script will take files or dirs as parameters and will back them up in a
presefined location, using tar. Problems arise when it will encounter files
or directories which contain spaces in their names.
On Sun, Apr 22, 2012 at 10:25 PM, Dom to...@rpdom.net wrote:
On 22/04/12 08:34, Cam Hutchison wrote:
Soare Catalinlolinux.soare@gmail.**com lolinux.so...@gmail.com
writes:
The script will take files or dirs as parameters and will back them up
in a
presefined location, using tar.
On 22/04/12 22:02, Soare Catalin wrote:
On Sun, Apr 22, 2012 at 10:25 PM, Domto...@rpdom.net wrote:
On 22/04/12 08:34, Cam Hutchison wrote:
Soare Catalinlolinux.soare@gmail.**comlolinux.so...@gmail.com
writes:
The script will take files or dirs as parameters and will back them up
in a
Hello fellow Linux supporters!
I apologise if this specific thread is off topic to this mailing list.
I've been having problems with a backup script and am not sure how to make
this work.
So far, Mr. Google hasn't helped me much -- maybe my search terms have been
as dumb as I'm feeling right
BK_FULLPATH=${BK_LOCATION}/BACKUP_${DATETIME}.tar.bz2
tar -cjf $BK_FULLPATH $BK_LIST
Il giorno 21 aprile 2012 10:07, Soare Catalin lolinux.so...@gmail.com ha
scritto:
Hello fellow Linux supporters!
I apologise if this specific thread is off topic to this mailing list.
I've been having
Scusa ho svagliato
BK_FULLPATH=${BK_LOCATION}BACKUP_${DATETIME}.tar.bz2
tar -cjf $BK_FULLPATH $BK_LIST
Il giorno 21 aprile 2012 10:07, Soare Catalin lolinux.so...@gmail.com ha
scritto:
Hello fellow Linux supporters!
I apologise if this specific thread is off topic to this mailing list.
Hallo Michelle,
Michelle Konzack [EMAIL PROTECTED] wrote:
Am 2005-08-19 13:05:25, schrieb Frank Dietrich:
Damit sollte es funktionieren:
NAME=`dialog --nocancel --stdout --inputbox Benutzername 8 40
21`
Wird nicht von allen dialog implementationen
Am 2005-08-20 09:07:36, schrieb Frank Dietrich:
Hallo Michelle,
Welche meinst Du? Vermutlich die die auf einem UNIX laufen. Auf die
hab ich keinen Zugriff. Kannst trotzdem mal schreiben bei welche-n/-m
es nicht geht.
Solaris 7 und Solaris 10.
Überprüft weil ich beide laufen habe. HP-UX und
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Und wieder einmal ich.
Ich habe ein Script von RedHat importiert nach Debian und es tut nicht
so in der bash, wie ich gerne möchte.
Am Anfang hat es mehrere Zeilen a la:
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Und da hakt es.
On [Fri, Aug 19 11:45], Lars Schimmer wrote:
Hi!
Aloha,
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Hmm, mit den Backticks macht man Kommando-Substitution. D.h. in diesem
Falle gibt das Kommando etwas aus, dann landet es in $NAME. Willst du
jedoch $NAME ausführen, dann
Hallo Lars,
Am 2005-08-19 11:45:31, schrieb Lars Schimmer:
Hi!
Am Anfang hat es mehrere Zeilen a la:
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Und da hakt es.
Das dialog --nocancel --inputbox Benutzername 8 40 21 ist noch kein
problem, das ganze aber unter NAME abzulegen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michelle Konzack wrote:
Hallo Lars,
Am 2005-08-19 11:45:31, schrieb Lars Schimmer:
Hi!
Am Anfang hat es mehrere Zeilen a la:
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Und da hakt es.
Das dialog --nocancel --inputbox
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Markus Meyer wrote:
On [Fri, Aug 19 11:45], Lars Schimmer wrote:
Hi!
Aloha,
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Hmm, mit den Backticks macht man Kommando-Substitution. D.h. in diesem
Falle gibt das Kommando etwas
Hallo Lars,
Lars Schimmer [EMAIL PROTECTED] wrote:
Am Anfang hat es mehrere Zeilen a la:
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Und da hakt es.
Das dialog --nocancel --inputbox Benutzername 8 40 21 ist noch
kein problem, das ganze aber unter NAME abzulegen schon.
Damit
On [Fri, Aug 19 12:33], Lars Schimmer wrote:
Bash 2.05b-26. Und nein, das kleine script von dir tut es bei mir nicht :-(
Wieder das selbe Verhalten, aufrufen, nichts passiert, return, script endet.
Es ist eine sarge Box, vor 2 Monaten installiert und nur Updates
installiert.
Ich bin ein wenig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Frank Dietrich wrote:
Hallo Lars,
Lars Schimmer [EMAIL PROTECTED] wrote:
Am Anfang hat es mehrere Zeilen a la:
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Und da hakt es.
Das dialog --nocancel --inputbox Benutzername 8 40 21 ist
Lars Schimmer [EMAIL PROTECTED] wrote:
Bash 2.05b-26. Und nein, das kleine script von dir tut es bei mir nicht :-(
Wieder das selbe Verhalten, aufrufen, nichts passiert, return, script endet.
Es ist eine sarge Box, vor 2 Monaten installiert und nur Updates
installiert.
Ich bin ein wenig
Frank Dietrich [EMAIL PROTECTED] wrote:
Hallo Lars,
Lars Schimmer [EMAIL PROTECTED] wrote:
Am Anfang hat es mehrere Zeilen a la:
NAME=`dialog --nocancel --inputbox Benutzername 8 40 21`
Und da hakt es.
Das dialog --nocancel --inputbox Benutzername 8 40 21 ist noch
kein problem, das ganze
On [Fri, Aug 19 14:12], Frank Küster wrote:
Ohne --stdout kommt ja nicht mal die Dialogbox. Das wäre ein
schwerwiegender Bug, zumal nichts darüber in der Manpage steht. Kann
das jemand auf sid reproduzieren?
Jep.
ii dialog 1.0-20050306-1 Displays user-friendly dialog boxes
Warum?
Markus Meyer [EMAIL PROTECTED] wrote:
On [Fri, Aug 19 14:12], Frank Küster wrote:
Ohne --stdout kommt ja nicht mal die Dialogbox. Das wäre ein
schwerwiegender Bug, zumal nichts darüber in der Manpage steht. Kann
das jemand auf sid reproduzieren?
Jep.
ii dialog 1.0-20050306-1
On [Fri, Aug 19 15:08], Frank Küster wrote:
Demnach sollte es doch mit foo=`dialog ... 21` funktionieren;
jedenfalls aber sollte eine Dialogbox gezeigt werden. Im Gegenteil, die
manpage rät sogar von --stdout ab:
Ok. Habe das Kleingedruckte nicht gelesen. Da muß jetzt auch zugeben,
daß das
Markus Meyer [EMAIL PROTECTED] wrote:
On [Fri, Aug 19 15:08], Frank Küster wrote:
Demnach sollte es doch mit foo=`dialog ... 21` funktionieren;
jedenfalls aber sollte eine Dialogbox gezeigt werden. Im Gegenteil, die
manpage rät sogar von --stdout ab:
Ok. Habe das Kleingedruckte nicht gelesen.
On [Fri, Aug 19 16:55], Frank Küster wrote:
Die eigentliche Frage ist doch, warum
foo=`dialog --nocancel --inputbox Benutzername 8 40 21`
auf einem (zumindest auf meinem) ganz normalen System keine Dialogbox
aufblendet (und foo auf setzt), während
Das hier habe ich in
Am 2005-08-19 13:33:49, schrieb Frank Küster:
Lars Schimmer [EMAIL PROTECTED] wrote:
Was sagt denn
which dialog
dpkg -S `which dialog`
Ich erinnere mich dunkel, dass irgendein anderes Paket auch ein
dialog-Binary installieren wollte...
dialog: /usr/bin/dialog
ls -Al /usr/bin/dialog
Am 2005-08-19 13:05:25, schrieb Frank Dietrich:
Hallo Lars,
Damit sollte es funktionieren:
NAME=`dialog --nocancel --stdout --inputbox Benutzername 8 40 21`
Wird nicht von allen dialog implementationen unterstützt
Frank
Greetings
Michelle
--
Am 2005-08-19 16:55:00, schrieb Frank Küster:
dialog --nocancel --inputbox Benutzername 8 40 2texmpfile
ein Fenster auftut und hinterher etwas in der Datei steht. Kriegt das
mit `` aufgerufene Kommando kein stdout?
auch bei
dialog --nocancel --inputbox Benutzername 8 40 texmpfile 21
? -
Michelle Konzack [EMAIL PROTECTED] wrote:
Am 2005-08-19 16:55:00, schrieb Frank Küster:
dialog --nocancel --inputbox Benutzername 8 40 2texmpfile
ein Fenster auftut und hinterher etwas in der Datei steht. Kriegt das
mit `` aufgerufene Kommando kein stdout?
auch bei
dialog --nocancel
Hello,
I have a problem with a bash script. The script (example) is very simple:
script.sh---
#!/bin/bash
echo hello
ssh PT-AGCMLX1 while true; do date; sleep 10s; done
When I start script.sh, look up its pid via ps and kill it, the
Am 17.05.2005 um 11:50 schrieb [EMAIL PROTECTED]:
I have a problem with a bash script. The script (example) is very simple:
#!/bin/bash
echo hello
ssh PT-AGCMLX1 while true; do date; sleep 10s; done
[..]
How can I change my script so that it kills all its child processes, if it
is
Hello,
I have a problem with a bash script. The script (example) is very
simple:
#!/bin/bash
echo hello
ssh PT-AGCMLX1 while true; do date; sleep 10s; done
[..]
How can I change my script so that it kills all its child processes,
if it
is killed itself ? I tried to use
On Tue, May 17, 2005 at 02:29:41PM +0200, [EMAIL PROTECTED] wrote:
I have a problem with a bash script. The script (example) is very simple:
script.sh---
#!/bin/bash
echo hello
ssh PT-AGCMLX1 while true; do date; sleep 10s; done
92 matches
Mail list logo
