Shell command fails in LC

[thatkeith]

Considering my recent post about spaces in file names the irony is strong with me today! Once y'all have stopped laughing, if anyone has a solution I'd love to hear it...
The bash -cl method works, but because the command sent with this needs to be quoted as a whole when I throw it at shell() I have trouble with paths that contain spaces... because of course they need to be quoted within this.

This:

Code: Select all

pdfjam --vanilla "/path/with spaces/input file.pdf" --nup 2x1 --frame false --landscape --outfile "/path/with spaces/output file.pdf"

needs to be put in this, within the quotes:

Code: Select all

bash -cl ""

but of course the quotes jump all over each other. :/

[Thierry]

Like this?

Not tested as I don't have pdfjam installed!

Code: Select all

// pdfjam --vanilla "/path/with spaces/input file.pdf" --nup 2x1
//                --frame false --landscape --outfile "/path/with spaces/output file.pdf"

   put sq( "/path/with spaces/input file.pdf") into INPUT_FILE
   put sq( "/path/with spaces/output file.pdf") into OUTPUT_FILE
   get  "pdfjam --vanilla [[INPUT_FILE]] --nup 2x1 --frame false --landscape --outfile [[OUTPUT_FILE]]"
   put merge( IT) into _pdfjam
   put shell( "bash -cl" && q( _pdfjam) ) into fld 1

Code: Select all

function q s
   return quote & s & quote
end q

function sq s
   return "'" & s & "'"
end sq

[thatkeith]

That's perfect, a great solution! I'll tinker with variations just for the educational fun of it, but this is *very* helpful.

[thatkeith]

I don't suppose it's possible to set the PATH to something by hand – or rather, by script?

It is !

Is it related to

Code: Select all

export PATH=$PATH:~/bin

by any chance?
My aim would be to have pdflatex not actually installed but stored somewhere accessible, with the path customised at runtime within the LC stack... Would this be crazy like a fool or like a fox?

k

[Thierry]

I don't suppose it's possible to set the PATH to something by hand – or rather, by script?

Is it related to

Code: Select all

export PATH=$PATH:~/bin

by any chance?

You're the winner of the day

My aim would be to have pdflatex not actually installed but stored somewhere accessible, with the path customised at runtime within the LC stack... Would this be crazy like a fool or like a fox?

Ok, let's imagine pdflatex is installed in: /crazy/fox

Here is 3 ways (entirely in LC) to make your pdfjam works!
There are slight differences in between those but would be a bit too long
to give a shell course...

Code: Select all

   get  "pdfjam --outfile [[OUTPUT_FILE]]"
   put shell( "PATH=$PATH:/crazy/fox;" & merge( IT))

OR:

Code: Select all

   put $PATH & ":/crazy/fox" into $PATH

   get  "pdfjam --outfile [[OUTPUT_FILE]]"
   put shell( merge( IT))

OR:

Code: Select all

   get  "/crazy/fox/pdfjam --outfile [[OUTPUT_FILE]]"
   put shell( merge( IT))

and I get rid of the second bash ( "bash -cl " ) as we know the fullpath!!

Hoping you get the idea?


Happy coding,

Thierry

[thatkeith]

Thanks! This is damn exciting stuff. I've just set up a spare (borrowed) Mac as a virgin system so I can be 100% certain I'm trying this out on something I haven't twisted up (yet).

[thatkeith]

Well, pdflatex is a stubborn little thing. (Translation: I can't quite figure out how to get it working!)

I have the pdflatex directory in an accessible location and I've added it to the $PATH environment variable. (When I run my test it checks to see if "pdflatex" is in $PATH and adds the path if not.) I'm having no problem referencing pdfjam or pdftk in their respective locations... but of course I'm *calling* those explicitly, whereas pdflatex is invoked by pdfjam rather than me.

Or is it possible that pdflatex (pdftex) *must* be installed? I'm really hoping to find a way to wrap everything up so it can be easily transported to a different machine and run under LC control without formally 'installing' pdflatex in the traditional sense.

Here's what $PATH looks like in LC:

Code: Select all

/usr/bin:/bin:/usr/sbin:/sbin:/Users/thatkeith/Desktop/unixtools/2017basic/bin/x86_64-darwin/pdflatex

And the PATH shown by calling env in Terminal

Code: Select all

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/thatkeith/Desktop/unixtools/2017basic/bin/x86_64-darwin/pdflatex

Whch is, er, slightly different (/usr/local/bin:). Is there a good place online I can go to read more about this stuff?

k

[[-hh]]

Thierry's PATH instructions are, as always, correct. But your TeX installation seems to be "out of bounds".
So this is my proposal:
Remove your old TeX installations and install TeXLive, for Mac via MacTeX (=an usual dmg), and everything is in its correct place: http://www.tug.org/mactex/

Then this works here (on Mac, for other OS the "export PATH..."-line has to be adjusted in a platform switch).

Code: Select all

local baseaddress="/Users/admin/myTeXdocs/"
on mouseUp
    set the shellcommand to "/bin/bash"
    set the defaultfolder to baseaddress -- the folder where "test.tex" resides
    put "export PATH=/Library/TeX/texbin:$PATH;" into txf   #<-- don't forget the semicolon (or cr) after this line
    put shell(txf &  " pdflatex -interaction nonstopmode test") into fld "OUT" 
end mouseUp

The resulting file "test.pdf" appears in baseaddress, the "log" in fld "OUT".

Edit: Added a missing semicolon. Thanks Thierry for the hint to that.

[thatkeith]

Huh. Well, to be clear I never doubted Thierry for a second; it was me that was in the dock.

My aim was (and still is, in hope) to be able to package up the required tools and, ideally, store them within the app package. This works well with exiftool and it appears that pdftk and pdfjam would also behave well... but maybe pdflatex can't be persuaded to play this particular game.

The MacTeX download is 3GB, which is fine for me but a likely showstopper for the average user. I just installed BasicTeX on this clean test machine and my calls to pdfjam within my LC stack work fine, just as they did on my regular Mac with TeX and a few other additions in place. BasicTeX is a 75MB download, which is a *much* easier thing to persuade people to get.

Even if I never achieve my goal this exercise hasn't been fruitless as I've learned quite a lot, both from Thierry's pointers (thanks!) and from the reading around those that I did. But damn and blast, I'm going to keep trying...

(Beginning with understanding your suggestion properly, a bit later.)

k

[[-hh]]

... but maybe pdflatex can't be persuaded to play this particular game.

Depends heavily upon what you wish to do with it.
TeX is the best typesetting engine on earth. To have full access to your local fonts available you need a full installation of XeTeX or XeLaTeX, possibly some packages may be missing in the BasicTeX installation for that.

For Windows there is also an 'extended basic' TeX which has a very high reputation: MiKTeX (around 200 MByte).
There they are moreover preparing downloads for Mac and (coming this summer) for linux. And there is already a portable installation for Windows available, other OS may follow: https://miktex.org/

Perhaps this can be an option for you:
To target a portable bundle for your stack/standalone, usable on Mac/Windows/linux?

[p.s. I already prepared a LC-TeX stack some time ago, may be I'll publish it soon.]

[Thierry]

Huh. Well, to be clear I never doubted Thierry for a second; it was me that was in the dock.

Thanks Keith, I learned a new English expression

As I said already, I know nothing about pdflatex but I have a strong experience about connecting tools
and all Unix utilities. I even teached computer science at the University of Strasbourg in France for few years
using Unix boxes and I have around 30 years of experience on developing/managing software projects...

My aim was (and still is, in hope) to be able to package up the required tools and, ideally, store them within the app package.
This works well with exiftool and it appears that pdftk and pdfjam would also behave well...
but maybe pdflatex can't be persuaded to play this particular game.

I just installed BasicTeX on this clean test machine and my calls to pdfjam within my LC stack work fine, just as they did on my regular Mac with TeX and a few other additions in place. BasicTeX is a 75MB download, which is a *much* easier thing to persuade people to get.

Ok, I did download BasicTeX and scan the package internals; there is a very well written installation script
which explains what the installation is doing. From this quick reading I believe the installation of BasicTeX will be standard
on all machines.

If I had to do the job, I will kept the BasicTeX package to do the installation (need to check license compatibilities!) and code an initialization script in LiveCode which will set up few globals ( I use global in the generic way; could be a property or a script local variable or even some fields in a database,..) to have the needed directories at hand.

After that, a classic shell() call should do the trick, following my former posts.

Even if I never achieve my goal ...

I don't see why you shouldn't !

Otherwise, Hermann's stack could be another nice alternative and maybe less work?


Bonne chance

Thierry

[thatkeith]

[Depends heavily upon what you wish to do with it.
TeX is the best typesetting engine on earth. To have full access to your local fonts available you need a full installation of XeTeX or XeLaTeX, possibly some packages may be missing in the BasicTeX installation for that.

My need here is purely the bursting of multi-page PDFs into single pages (with pdftk), trimming off inner bleed where that's set and slicing spreads into separate pages (pdfjam piggybacking on pdflatex), then reassembling the PDF into imposed order for 'zine-style booklet printing (again, pdfjam/pdflatex). There's no typesetting needed, and the ~100MB installation of BasicTeX did the job perfectly!

A portable bundle is exactly what I'm hoping to achieve. Was that what your LC-TeX stack involves? If you have the time and decide to publish what you've done in this area – portable bundle or not – I'd be very interested to see it.

k

[thatkeith]

Huh. Well, to be clear I never doubted Thierry for a second; it was me that was in the dock.

Thanks Keith, I learned a new English expression

For clarification, it's dock as in courtroom rather than anything to do with ships.

As I said already, I know nothing about pdflatex but I have a strong experience about connecting tools
and all Unix utilities. I even teached computer science at the University of Strasbourg in France for few years
using Unix boxes and I have around 30 years of experience on developing/managing software projects...

This explains a lot!

If I may ask a question: if, for some reason, you wanted to take a Unix utility that's normally set up to be found through a customised $PATH, and have it found in a non-standard location...

• Are there locations that you'd expect to work and not to work?
• For the former, would you expect just adding the relevant :/path/to/thingy to $PATH to do the trick, or are there other likely gotchas that I'm blissfully unaware of?

(Whoops, two questions...)

k

[Thierry]

If I may ask a question: if, for some reason, you wanted to take a Unix utility that's normally set up to be found through a customised $PATH, and have it found in a non-standard location...

• Are there locations that you'd expect to work and not to work?
• For the former, would you expect just adding the relevant :/path/to/thingy to $PATH to do the trick, or are there other likely gotchas that I'm blissfully unaware of?

Ok, I believe that any serious coded utility installed properly and anywhere in a disk
will work as long as the $PATH has been updated during the installation.

As it seems the $PATH is set up *only* for interactive mode in your case,
you have to catch this $PATH as shown in one of my previous post.

In other words, you don't care about the fullpath of any installed app/utilities as long as the $PATH has been updated.

However, as coders are humans, then all I said previously might be also wrong !
But I don't believe this as far as latex/tex is concerned.

Does that answer your questions?

Regards,

Thierry

[[-hh]]

Hi Keith and Thierry.

@ $PATH
If we use export for setting the $PATH in a shell() function (as I did above) then this is valid only for exactly this shell-session. I think this is an advantage because we don't disturb user's settings by that.

@portables
Cross-platform: Problematic are the many symlinks that are handled different for different filesystems (NTFS, fat32, HFS+).

Good: The general TeXLive has a "-portable" option when installing (= a 'bundled' installation). So that we can have 'portable' installation for each supported platform.

[And there are, BTW, also online-TeX-systems available.]

But I think these two targets

1. Run and interact with TeX from a LiveCode stack
2. Get a valid TeX installation for the current platform

shouldn't be connected as there are no specific requirements needed for LiveCode, only the path to the main TeX directory.

So my TeX-stack requires a valid TeX-installation. The files it creates will run on any machine that has a valid TeX-installation (incl. the needed packages), no matter the OS. It is nothing else than a primitive GUI showing some examples reaching from a simple letter up to a template for the slides of a talk. For regular work there are excellent specialized text editors, especially TeXShop (Mac) and TeXWorks (Mac/Win/linux).

Of course it is a secondary target to support the non-TeX-users with a (bundled) TeX-installation.

Ciao, Hermann