Re: bash cgi script dosent works from the browser
On Sat, Oct 29, 2011 at 01:30:54PM -0700, dan12341234 wrote: > 1 when im trying to load the page http://server1/hello.cgi it doas not > opened, instead it is saved as a file. Configuring your web server to run CGI programs (instead of returning the source code to the browser as a file) is well outside the scope of the bug-bash mailing list. Try asking for assistance in a forum dedicated to users of your web server software.
script to provide responses to prompts (badly written C program)
Hi,
please accept my apologies, as this is my first post here. I'm sure
I'm asking a very stupid questions, but I'm kind of stuck with this
...
The Problem: a badly written C program (mktrace) that doesn't accept
input as usual.
E.g. you cannot do this: 'mktrace filename', nor this 'mktrace < filename'
Instead, you have to run it like this:
[fernan@host] mktrace
warning: this program uses gets(), which is unsafe.
enter FASTA filename: (type filename here)
enter output filename: (type another filename here)
which of course does not make it easy when you have to run mktrace on
1000 files.
I've started playing with bash, trying to work around this, with mixed success:
This doesn't work:
#!/bin/bash
mktrace
echo "filename"
echo "output"
Nor this:
#!/bin/bash
mktrace | {
echo "filename"
echo "output"
}
However, this kind of works (though I don't quite understand why):
#!/bin/bash
find . -type f -name '*.fasta' | {
while read f
do
mktrace
echo "$f"
echo "$f.ab1"
done
}
In this latter case, my script gets mktrace to do its magic, BUT:
i) only for one file in the directory (there are many files that match
the globbing pattern)
ii) it overwrites the original .fasta file with the expected binary
output, and generates a new file (*.phd.1), as expected.
[Note: in addition to the output filename specified, mktrace generates
another output file, with the same namebase but ending in '.phd.1']
Any idea or suggestion would be much appreciated. I'm particularly
interested in understanding and learning along the way :)
Cheers,
--
fernan
Re: script to provide responses to prompts (badly written C program)
On Mon, Oct 31, 2011 at 6:14 PM, Fernan Aguero wrote:
> Hi,
>
> please accept my apologies, as this is my first post here. I'm sure
> I'm asking a very stupid questions, but I'm kind of stuck with this
> ...
>
> The Problem: a badly written C program (mktrace) that doesn't accept
> input as usual.
>
> E.g. you cannot do this: 'mktrace filename', nor this 'mktrace < filename'
>
> Instead, you have to run it like this:
>
> [fernan@host] mktrace
> warning: this program uses gets(), which is unsafe.
> enter FASTA filename: (type filename here)
> enter output filename: (type another filename here)
>
> which of course does not make it easy when you have to run mktrace on
> 1000 files.
>
>
> I've started playing with bash, trying to work around this, with mixed
> success:
>
> This doesn't work:
> #!/bin/bash
> mktrace
> echo "filename"
> echo "output"
>
> Nor this:
> #!/bin/bash
> mktrace | {
> echo "filename"
> echo "output"
> }
>
> However, this kind of works (though I don't quite understand why):
> #!/bin/bash
> find . -type f -name '*.fasta' | {
> while read f
> do
> mktrace
> echo "$f"
> echo "$f.ab1"
> done
> }
>
>
> In this latter case, my script gets mktrace to do its magic, BUT:
>
> i) only for one file in the directory (there are many files that match
> the globbing pattern)
> ii) it overwrites the original .fasta file with the expected binary
> output, and generates a new file (*.phd.1), as expected.
>
> [Note: in addition to the output filename specified, mktrace generates
> another output file, with the same namebase but ending in '.phd.1']
>
> Any idea or suggestion would be much appreciated. I'm particularly
> interested in understanding and learning along the way :)
>
> Cheers,
>
> --
> fernan
>
>
You should probably use expect instead of trying to get Bash to do it.
--
Visit serverfault.com to get your system administration questions answered.
Re: script to provide responses to prompts (badly written C program)
Fernan Aguero wrote: > please accept my apologies, as this is my first post here. I'm sure > I'm asking a very stupid questions, but I'm kind of stuck with this > ... The bug-bash mailing list is not quite the right place for this type of question. Better to ask it in help-gnu-utils instead. The bug-bash list is for all aspects concerning the development of the bash shell. That sort'a overlaps with the *use* of the shell and shell *utilities* but not really. The developers would be overwhelmed with outside discussion that doesn't have anything to do with the development of the shell. I am going to send an answer to you but in another message. I will CC the help-gnu-utils mailing list. Let's move any discussion and followup to help-gnu-utils instead of here. Bob
[patch] builtins: fix parallel build between top level targets
the top level Makefile will recurse into the defdir for multiple targets
(libbuiltins.a, common.o, bashgetopt.o, builtext.h), and since these do not
have any declared interdependencies, parallel makes will recurse into the
subdir and build the respective targets.
nothing depends on common.o or bashgetopt.o, so those targets don't get used
normally. this leaves libbuiltins.a and builtext.h. at a glance, this
shouldn't be a big deal, but when we look closer, there's a subtle failure
lurking.
most of the objects in the defdir need to be generated which means they need
to build+link the local mkbuiltins helper. the builtext.h header also needs
to be generated by the mkbuiltins helper. so when the top level launches a
child for libbuiltins.a and a child for builtext.h, we can hit a race
condition where the two try to generate mkbuiltins, and the build randomly
fails.
so update libbuiltins.a to depend on builtext.h. this should be fairly simple
since it's only a single target.
--- a/Makefile.in
+++ b/Makefile.in
@@ -674,7 +674,7 @@
$(RM) $@
./mksyntax$(EXEEXT) -o $@
-$(BUILTINS_LIBRARY): $(BUILTIN_DEFS) $(BUILTIN_C_SRC) config.h
${BASHINCDIR}/memalloc.h version.h
+$(BUILTINS_LIBRARY): $(BUILTIN_DEFS) $(BUILTIN_C_SRC) config.h
${BASHINCDIR}/memalloc.h ${DEFDIR}/builtext.h version.h
@(cd $(DEFDIR) && $(MAKE) $(MFLAGS) DEBUG=${DEBUG} libbuiltins.a ) ||
exit 1
# these require special rules to circumvent make builtin rules
signature.asc
Description: This is a digitally signed message part.
