"Christopher McDonald" <ch*i*.*c*o*a*[email protected]*a*e*u*a*> wrote:
> Hi Lee, I appreciate the sentiment of your your question :-)
> "Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:
> > For assignment 2, are there any restrictions on the software out shell script is
> > permitted to use? For example, could we extend haversine.c To add functionality, or call
> > Perl or Python scripts?
> The goal of this unit, and hence its assessments, is to learn how to use the variety of small tools,
> using them in combination with each other and the file-system.
> So 'opening-up' solutions to include bespoke Python scripts or C programs is not really in the spirit of
> that goal.
> > I’ve been curious to ask: in the context of shell scripting, is using Perl or Python from
> > within a shell script philosophically different to using tools like awk?
> That's a good question.
> Firstly, I'd argue that Perl is effectively 'dead' (not just in name), and is decreasingly used in new
> projects where Python is feasible. But that aside...
> I don't think (just through my reading) that many people write 'one-liner' Python scripts in preference
> to a standard Unix utility, unless they're not aware of the Unix utility, or think it has some
> On that, you may like to read:
> UNIX Style, or cat -v Considered Harmful
> As Python becomes even more pervasive, that may change, but at present there's still some advantage in
> having may quick-to-invoke compiled C utilities, that have been designed to work together. And there's
> still a bit of evolution in progress ( "sort | uniq" often subsumed by "sort -u", and "wc -l" being
> replaced by "grep -c ." )
> Having a toolbox of existing utilities with which (after some time), we don't have to think too much
> about, offers advantages for rapid prototyping of solution and, often, those solution just set to
> persist for years beyond their use-by-date, but haven't required modification.
> I'm unsure how many Python developers have a curated toolbox of Python one-liners but, if they did, I
> imagine that they'd be proficient enough in Python to prefer (or be tempted to) to build their whole
> solutions in Python anyway.
> I've left AWK in this unit, for at least another year, because it is still used for one-liners, as
> you'll see in lots of offered answers on stackoverflow. In recent years support for typed variables in
> shells have improved, but AWK (and Python) still hold advantage if associative arrays are the best
> So, yes, I'd argue that our Task #3 would be better implemented in Python, alone, but our goal here is
> not to build the best or most efficient solution, but to demonstrate our understanding of the command
> line utilities in combination.
Thanks for the detailed and helpful reply, Chris. I really appreciate it and what you're saying makes sense.
I only mention Perl specifically as it seems like it was an early evolution of sh, awk and sed. From
> "The Perl languages borrow features from other programming languages including C, shell script (sh), AWK,
So in the case of the assignment, we could conceivably use something like bc for the numerical component?