C as a scripting language

[Ian Collins]

I'd probably have written the whole thing as a shell script,

Or use more than one tool form the box.

The outer loop can be simplified to (and made more portable):

while( --argc > 0 )
{
const char* file = argv[argc];
...
}


If the program is run with

../a.out `ls *.c`

It will still fail with file names with spaces, but no sane developer
has spaces in source file names, do they?

 

[jacob navia]

So there is another concrete characteristic of a "reg". Someone
who has never posted any code to the group. I had previously
concluded that the "regulars" consists solely of CBF, but clearly
the group of "regulars" is completely empty.

Mr Falconer at least tried to contribute something to the community.
I have included his ggets in lcc-win, because it is useful and
because I appreciate people that try to contribute to the community
even if I disagree with him in almost everything else.

 

[Chris McDonald]

Common widsom says that python, ruby or similar are good for scripting,
but C is not the right tool for it.

Here is a small "benchmark" that shows that C can be used as a
scripting language in the same way as, for instance, ruby.

Well it only took about 2 follow-ups to this thread before it was smashed
by those complaining about Jacob, lcc, the mantra of the newsgroup -
and it wouldn't be a real thread without ggets getting a run...

Unsurprisingly, hardly any comments about the actual subject of the thread.

I haven't used it recently, but it would seem very easy to develop a
C-interpreter (for some people's understanding of 'C') using the Ch
embeddable interpreter: http://www.softintegration.com/

This seems a better approach than compiling C code snippets on the fly.

 

[Boon]

Keith wrote [that *windows* lcc-win doesn't understand popen...]

Obviously I am using Unix lcc-win,

Did you say that? What makes it obvious?

popen was a dead giveaway.

 

[gwowen]

This would be only a bit larger if you want to count compilation and

run-time errors.  It would still probably fit on one line.

#!/bin/bash
# Maybe slightly more than one line
filecount=0
compcomplete=0
runcomplete=0
for f in *.c
do
filecount=$(( $filecount + 1 ))
exename="${f%.c}".exe
gcc -o "${exename}" "$f" &&
compcomplete=$(( $compcomplete + 1)) &&
./${exename} &&
runcomplete=$(( $runcomplete + 1 ))
done

echo $filecount Files
echo $(( $filecount - $compcomplete )) compilation error
echo $(( $filecount - $runcomplete )) runtime errors

The moral of the story: use the right tool for the job.  In this case,
neither ruby nor C seems to be the right tool.

Amen.

 

[jacob navia]

#!/bin/bash
# Maybe slightly more than one line
filecount=0
compcomplete=0
runcomplete=0
for f in *.c
do
filecount=$(( $filecount + 1 ))
exename="${f%.c}".exe
gcc -o "${exename}" "$f" &&
compcomplete=$(( $compcomplete + 1)) &&
./${exename} &&
runcomplete=$(( $runcomplete + 1 ))
done

echo $filecount Files
echo $(( $filecount - $compcomplete )) compilation error
echo $(( $filecount - $runcomplete )) runtime errors


Amen.

Both ruby and C keep a list of files that failed. You fail
to do that.

But it is a good first attempt

 

[jacob navia]

Keith wrote [that *windows* lcc-win doesn't understand popen...]

Obviously I am using Unix lcc-win,

Did you say that? What makes it obvious?

popen was a dead giveaway.

As it was the use of "ls"

 

[James Kuyper]

Tristan Miller wrote:
....

You've produced two enormous monstrosities here where a single command line
in a decent interactive shell would have done the job. In bash, for
example:

for f in *.c; do gcc $f && ./a.out; done

The specifications given above include actually running the programs
after they've been compiled.

This would be only a bit larger if you want to count compilation and
run-time errors. It would still probably fit on one line.

It's clearly possible, and I think it could be done more easily by a
shell script than either of the examples jacob gave. However, I
seriously doubt that it can be done in a single line, and I'm positive
that doing it in one line would be a bad idea, if only because it would
be harder to understand than it need be.

 

[Ed Prochak]

Common widsom says that python, ruby or similar are good for scripting,
but C is not the right tool for it.
[]

Both programs use identical algorithms:
(1) The list of *.c files will be established. Ruby uses a list, C uses
     a pipe connected to another process that sends a line at a time.
(2) For each file the compiler is called, then the linker and the
     resulting program. Statistics are gathered.
(3) A printout at the end of the run lists the failures.

The length in source code of both programs is very similar.

The running time of both programs is identical.

I wrote the C program, and a friend wrote the ruby program. It was
for testing the Unix version of lcc-win, i.e. both programs are
used in a "production" setting.

I think that both languages are perfectly equivalent in this example.

The next example I will post is web programming.

Thanks for your attention.

Please, not another C shell! 8^(

make it go away. make it go away!

Ed

 

[Chris Dollin]

Common widsom says that python, ruby or similar are good for scripting,
but C is not the right tool for it.

Here is a small "benchmark" that shows that C can be used as a
scripting language in the same way as, for instance, ruby.
(fx:snip)

Here is a solution using the "ruby" language:

(fx:snip ruby)

If I may offtopically say so, this is a completely horrible solution,
twice as long and ten times less transparent than it need be.

The length in source code of both programs is very similar.

A factor of two isn't "very similar".

The running time of both programs is identical.

Well, yes, the run-time is going to be dominated by the cost of
compiling and maybe running.

Here's my hacked ruby version. You could probably use this as the
basis for a shorter C version. I changed the command strings (obviously)
and dumped print-as-we-go in favour of print-problems-at-end.

#/usr/bin/ruby -w
def run_and_collect(file_list)
run_failures = []
run_successes = []
compile_failures = []
#
file_list.each do |file|
compiledOK = system( "gcc -O #{file} -o runMe" )
if compiledOK
ranOK = system( "./runMe" )
(ranOK ? run_successes : run_failures).push( file )
else
compile_failures.push(file)
end
end
puts("Compilations: #{file_list.size}" )
puts( " failed: #{compile_failures.size} (#{compile_failures})\n" );
puts( "Runs: #{run_successes.size + run_failures.size}" )
puts( " failed: #{run_failures.size} (#{run_failures})\n" );
end

run_and_collect(ARGV)

 

[James Kuyper]

Both ruby and C keep a list of files that failed. You fail
to do that.

Possibly because your specification of the problem to be solved failed
to require it.

 

[Keith Thompson]

Keith wrote [that *windows* lcc-win doesn't understand popen...]

Obviously I am using Unix lcc-win,

Did you say that? What makes it obvious?

popen was a dead giveaway.

popen was a dead giveaway that the program was intended for a
Unix-like system. I suppose jacob's name at the top was probably a
dead giveaway that some variant of lcc-win was being used, but I
didn't want ot make that assumption.

 

[Chris Dollin]

Jacob wrote:
Keith wrote [that *windows* lcc-win doesn't understand popen...]

Obviously I am using Unix lcc-win,

Did you say that? What makes it obvious?

popen was a dead giveaway.

popen was a dead giveaway that the program was intended for a
Unix-like system. I suppose jacob's name at the top was probably a
dead giveaway that some variant of lcc-win was being used, but I
didn't want ot make that assumption.

I thought the "../lcc" in the `system` argument was a bit of a giveaway.

 

[jameskuyper]

Greetings.



Yes, and? ./a.out accomplishes this on *nix.

You are, of course, correct. I always name my executables something
else, but I'm well aware of the fact that a.out is the default, so I'm
not sure how I managed to miss that.

Depends if you need anyone else to understand it.

At an absolute minimum, I need to be able to understand it, even if no
one else needs to do so, and trying to do all of those things on a
single line would push the limits on my own ability to understand what
I was writing.

... If it's just a one-off
script, like the dozens I need to write each day, then there's no reason
why it couldn't (and shouldn't) be written directly at the command prompt
in one line. In another post I gave an example of this; it's about 110
characters long.

Your version doesn't meet the specification that a count of
compilation errors and runtime errors be collected and reported.
However, the same is true of both of jacob's versions, too. All three
"scripts" count only the number of failed compilations and the number
of failed runs, but not the number of errors. On a unix-like system
I'd pipe the compiler output to "grep -i error | wc -l", resigning
myself to the fact that it would produce an overcount due to the
possibility of the string "error" coming up for some reason (such as a
file name) in some context other than an error message.

 

[Flash Gordon]

Well it only took about 2 follow-ups to this thread before it was smashed
by those complaining about Jacob, lcc, the mantra of the newsgroup -
and it wouldn't be a real thread without ggets getting a run...

Unsurprisingly, hardly any comments about the actual subject of the thread.

Before you can compare implementations of a scripting job in different
languages you first have to get the requirements for the scripts and
working versions of the scripts.

I haven't used it recently, but it would seem very easy to develop a
C-interpreter (for some people's understanding of 'C') using the Ch
embeddable interpreter: http://www.softintegration.com/

This seems a better approach than compiling C code snippets on the fly.

Or simply use a C-like language designed for scripting such as csh or tcsh

 

[jfbode1029]

Ian Collins said:

It will still fail with file names with spaces, but no sane
developer has spaces in source file names, do they?

No sane user[1] inserts spaces into any file name.

If the file system allows it, then why not? Other than giving CLI-
based tools fits, that is.

 

[Keith Thompson]

Mark wrote:
Jacob wrote:
Keith wrote [that *windows* lcc-win doesn't understand popen...]

Obviously I am using Unix lcc-win,

Did you say that? What makes it obvious?

popen was a dead giveaway.

popen was a dead giveaway that the program was intended for a
Unix-like system. I suppose jacob's name at the top was probably a
dead giveaway that some variant of lcc-win was being used, but I
didn't want ot make that assumption.

I thought the "../lcc" in the `system` argument was a bit of a giveaway.

Yeah, that too.

 

[luserXtrog]

(e-mail address removed) said:

On Mar 27, 3:23 am, Richard Heathfield <[email protected]>
wrote:
Ian Collins said:
<snip>
It will still fail with file names with spaces, but no sane
developer has spaces in source file names, do they?
No sane user[1] inserts spaces into any file name.
If the file system allows it, then why not?  Other than giving
CLI- based tools fits, that is.

That sounds like a pretty good reason all on its own.

It doesn't bother any of the CLI-based tools on my computers...

ls -1 | while read i ; do file "$i" ; done
a file with spaces in.bat: ASCII text
C: directory
CTX.DAT: Java serialization data, version 5
My Pictures: directory
My Videos: directory
wibble.sh: POSIX shell script text executable

WHY DO ONES LOOK LIKE ELLS?
arrgggh.
Nice script, though. If I do that a few more times, I might just
remember the shell syntax for a loop.

 

[Ian Collins]

Perhaps you ought to grow up.

Oh look, a pig just flew past my window....

 

[Ian Collins]

Nice script, though. If I do that a few more times, I might just
remember the shell syntax for a loop.

Which shell!