Translate BASH source

[Lars Eighner]

Will 'require' serve as a translation for Bash 'source' ('.').

I am trying translate a BASH script.

The Bash script includes something like

. filefoo

where filefoo is a whole bunch of variable assignments.

It is easy enough to translate the variable assignments to perl.

If I tanslate filefoo and stick a 'return 1;' at the bottom, would 'require
filefoo' be a reasonable translation of the Bash . filefoo?

 

[Ben Morrow]

Will 'require' serve as a translation for Bash 'source' ('.').

I am trying translate a BASH script.

The Bash script includes something like

. filefoo

where filefoo is a whole bunch of variable assignments.

'require' has slightly different semantics. In particular, 'require'
will always (and only) search the directories listed in @INC, whereas
'.' will search $PATH iff filefoo doesn't contain a slash.

If you need to keep the 'search $PATH' semantics you'll need to
implement it yourself. If you just want to load a file from the given
path (without doing any searching), use 'do' instead. If you're happy to
install filefoo somewhere in @INC instead of somewhere in $PATH, use
'require'.

It is easy enough to translate the variable assignments to perl.

Well... it's easy enough to translate them into *bad* Perl. If you
follow the advice everyone in this group gives you and 'use strict' and
declare your variables with 'my', you'll find you can't get at them from
outside the file they're declared in. This is a feature .

A simple way round, if you're just looking to get the script working
rather than write it well, is to declare the variables with 'our' in
both files. A better answer would be to declare a single %config hash,
and have your included file set that rather than a whole lot of separate
variables. A much better answer would be to use some well-known config
file format, and something like Config::Any to load it for you.

If I tanslate filefoo and stick a 'return 1;' at the bottom, would 'require
filefoo' be a reasonable translation of the Bash . filefoo?

It's not usual to use 'return' when ending a required file with a true
value; a line just containing '1;' at the end of the file is much more
common. While you can use 'return' to leave a required file partway
through, I'd consider that very confusing behaviour.

Ben

 

[Lars Eighner]

The literal translation of that would be do.
do 'filefoo';

Having said that, I'm not sure a literal translation from bash to Perl
would make a good program. Is there any reason you need to translate it?

Well, yes. It doesn't work.

I want Nanoblogger to work for me on a FreeBSD system. I have overcome many
obstacles so far, but Nanoblogger occasionally emits empty documents,
apparently at random, and this is a silent gotcha. Clearing cache,
previously generated documents, and so forth, on each attempt results in
different pages that coming out empty. On various runs I get every document
out right sometimes, but rarely get them all out. I suspect BASH limits
might be the culprit, but they are all maxed out.

I suspect the author's point in Nanoblogger is all the wonderful things you
can do with Bash and stream tools (I've learned more sed in this process than
I ever wanted to know). And when it works, it works great.

I, however, am not interested in a Bash demo, but in a working blog. The
main features I like about Nanoblogger are:
*flat file database
*only requires a command line editor
*does not require a javascript-enabled browser

I want to use it to generate static pages. I won't have direct entry of
user comments with forms, etc. Security, in short, is no issue. But
avoiding OO perl modules is. I'm not interested in a bunch of scoping crap
and inscrutable notation. And the reason this particular question is here
is because when I consult the perl docs with simple issue like this,
I get a bunch of Module::OO::Crap instead of a simple explanation of how to
include some code from another file.

This is why I fear Perl 6: because so far as I can tell, it only promises
more of the same.

 

[Lars Eighner]

I'm sure there are more blogs that do that. If not, building one from
scratch might be easier that translating this one. Also, it will probably
take you a lot less than 2700 LOCs.

You are probably right --- and no doubt eliminating all of the stuff I know
I will never want would make it much shorter, even if I can't make it
better. Let's say this is a warm-up exercise.