On 12 July 2013 10:36, Patrick Gundlach wrote:
> Hi,
>
> is it possible to programatically set the exit status of the LuaTeX run?
>
> say something like this:
>
> tex.exitstatus = 1
>
> or \exitstatus=1 \bye
\directlua{os.exit(1)}
Cheers,
Tomek
___
d
On 22 August 2010 18:06, Taco Hoekwater wrote:
> Hi,
>
> Here is a first attempt at a cheat sheet for luatex 0.60.
>
> All comments are welcome.
Great! I love these cheat sheets (poor memory, you know ;)
Cheers,
Tomek
___
dev-luatex mailing list
dev-
Continuation of thread from:
http://tug.org/pipermail/tex-live/2010-April/025466.html
On 22 April 2010 00:03, Manuel Pégourié-Gonnard wrote:
> T T a écrit :
>> Yes, I'm quite familiar by now how those things work in texlua and
>> perl. Still, I'm really baffled how tho
On 15 April 2010 17:46, T T wrote:
> On 15 April 2010 17:18, Taco Hoekwater wrote:
>> T T wrote:
>>>
>>> On 15 April 2010 16:34, Taco Hoekwater wrote:
>>>>
>>>> Or any other older version, I'm sure. All commandline related stuff
>>
On 15 April 2010 17:18, Taco Hoekwater wrote:
> T T wrote:
>>
>> On 15 April 2010 16:34, Taco Hoekwater wrote:
>>>
>>> Or any other older version, I'm sure. All commandline related stuff
>>> is in luainit.w, I think.
>>
>> I pro
On 15 April 2010 16:34, Taco Hoekwater wrote:
>
> Or any other older version, I'm sure. All commandline related stuff
> is in luainit.w, I think.
I probably need to svn up, because I can only find luainit.c, no luainit.w.
> And now I suddenly see what is going wrong: your backslash is
> intercep
On 15 April 2010 15:31, Taco Hoekwater wrote:
> T T wrote:
>>
>> $ texlua \\.\H:\DEV\scratch\arg0test.lua
>> No script file given
>
> There is a stat() test in luainit.w (the is_readable macro)
> which probably fails for UNC files. I can try a patch, but it
>
On 15 April 2010 15:09, Hans Hagen wrote:
> On 15-4-2010 3:57, T T wrote:
>
>> $ texlua \\.\H:\DEV\scratch\arg0test.lua
>> No script file given
>
>
> puting something in front of a drive specification is wrong anyway i think,
> just try
>
> dir ".\c:&
Hi,
I've noticed an odd thing with texlua on Windows, here's the code and
output illistrating it. The test script arg0test.lua is a simple
one-liner:
print(unpack(arg, 0))
Call with no arguments (note the conversion of \ to /):
$ texlua H:\DEV\scratch\arg0test.lua
H:/DEV/scratch/arg0test.
On 17 March 2010 12:18, Élie Roux wrote:
> 2010/3/17 T T :
>>
>> But if non-cygwin binaries are used, why would you want to detect
>> cygwin at all?
>
> Because that's what I'm using, and thus I guess I'm not the only one ;-)
>
>> The best you c
On 17 March 2010 09:55, Élie Roux wrote:
>
> Anyway, as most users will use binaries compiled under non-cygwin in
> their cygwin system, thus it does not solve the cygwin detection
> problem.
But if non-cygwin binaries are used, why would you want to detect
cygwin at all? The best you can do is t
On 16 March 2010 10:53, T T wrote:
>
> FYI, in our perl code we use the "abs_path" function from the cwd
> module for the functionality I was after but I don't know how's that
> implemented.
Out of curiosity I had a look at perl sources. They use realpath
implemen
On 16 March 2010 08:20, Taco Hoekwater wrote:
>
> Just wondering: what does it return for ".." then?
Path to the one dir up from the current dir.
> I've given up on a Unix C function for this there are just too many
> potential problems with symlinks. As you are using mkdir now also,
> would it
On 16 March 2010 08:01, Élie Roux wrote:
>
> I just thought about something: in a script we need to detect if,
> under windows, luatex is run under cygwin or not (cygwin and
> non-cygwin are the same binary for me). Currently we do something like
I'm not sure if I understand you correctly. I've
On 15 March 2010 15:54, Taco Hoekwater wrote:
>
> My man page for realpath(3) says:
>
> BUGS:
> Avoid using this function. Its is broken by design
>
> But it does not offer an alternate solution.
Bummer.
> Looks like it would need private code, which is not a lot of fun to
> write (unless there
On 15 March 2010 12:03, Taco Hoekwater wrote:
>
> Oh, alright then. Patch applied (#3494)
Thanks. One more patch for your consideration for something I needed
recently: getting absolute, canonical file paths. In principle this
can be implemented in pure Lua with the current lfs module, but
gettin
On 15 March 2010 07:47, Taco Hoekwater wrote:
> T T wrote:
>
>> I would also suggest to remove the 'svn up' from the script. While
>> working on/testing local changes you do not necessarily want to keep
>> the working copy in sync with the head. A
On 12 March 2010 09:59, Taco Hoekwater wrote:
> Taco Hoekwater wrote:
>>
>> T T wrote:
>>>
>>> followed. This short/long file naming duality is a legacy of an ugly
>>> hack MS once pulled, and it is unlikely to ever disappear, I'm afraid.
>>
&g
On 3 March 2010 14:07, Taco Hoekwater wrote:
> T T wrote:
>>
>> From less essential functionality I would also love to have access to
>> MessageBox for a minimal GUI functionality.
>
> This is something that will not go in the core, so that would have
> to be an ext
On 2 March 2010 12:57, Hans Hagen wrote:
>
> isn't there a flag somewhere that makes env vars expand into long paths?
Not to my knowledge but even if such a flag exists it doesn't help
much. Short paths can appear in any place where file name is expected
and to write correct code one can never as
On 2 March 2010 09:21, Hans Hagen wrote:
> On 2-3-2010 8:01, Taco Hoekwater wrote:
>> T T wrote:
>>>
>>> With the other thread asking to add readlink, I would also like to ask
>>> for an addition of Windows specific GetShortPathName. Without this
>>&
Hi,
With the other thread asking to add readlink, I would also like to ask
for an addition of Windows specific GetShortPathName. Without this
function it is impossible to check if two paths point to the same
place.
However, I'm not sure if beefing up LuaTeX with this kind of
functionality is the
2009/12/21 Hans Hagen :
>> Something seems to be wrong with the library:
>>
>> For example
>>
>> $echo -n "test" | md5sum 098f6bcd4621d373cade4e832627b4f6 -
>>
>> but
>>
>> print(md5.sumhexa("test")) gives
>>
>> 0944483cd90a293923c8244520132de1
>
> strange, as on my machine (vista) it gives
>
> 09
2009/12/2 Taco Hoekwater :
>
>> Does this incur any performance penalty, i.e. does
>> kpathsea reinitializes itself from scratch when my object goes out of
>> scope and set_program_name is called again?
>
> When a kpse:new() variable goes out of scope or when you want to change
> its program name y
2009/12/2 Taco Hoekwater :
>
> The object interface gives you a kpse object that is totally
> separate from luatex, the procedural interface reuses the kpse
> that luatex itself uses for its own lookups.
Thanks for explaining this.
>
> Whether the distinction matters to you depends on what you wa
Hi,
Is there any reason to prefer object interface to kpathsea over the
procedural one? I'm asking in particular in the context of
dofile(arbitrary_script), where arbitrary_script may also use kpathsea
(either through procedural or object interface).
Cheers,
Tomek
___
2009/11/27 Taco Hoekwater :
>
>
> T T wrote:
>> 2009/11/27 Taco Hoekwater :
>>> T T wrote:
>>>> The above changes do not change the behaviour of currently working
>>>> cases, only the failing ones and those resulting in wrongly parsed
>>>&
2009/11/27 Taco Hoekwater :
> T T wrote:
>>
>> The above changes do not change the behaviour of currently working
>> cases, only the failing ones and those resulting in wrongly parsed
>> arguments being passed to the child process are affected.
>>
>> If that
2009/11/24 Hans Hagen :
> Reinhard Kotucha wrote:
>>
>> On 23 November 2009 Taco Hoekwater wrote:
>>
>> > Let's put it this way: windows command line processing does not
>> > agree with my neurons, so I have stayed way from it as much as
>> > possible (and will continue to do so).
>> > > A goo
2009/11/24 D. R. Evans :
> I'm probably being blind, but I can't find any instructions about
> downloading the source from svn and building it.
>
> Can some kind person please point me to such instructions?
I just tried to do it yesterday for the first time. Building the
trunk under mingw with 's
2009/11/24 Taco Hoekwater :
>
> If we decide to keep the binary modules support (which is experimental
> right now) then in the future, it would be nice to build our 'own' lua
That would be very welcome, indeed. It could make lua(tex) not only a
common scripting solution, but also a common platfor
Hi,
I saw in another post that loading of binary modules has been enabled
in luatex (great!) that requires a stock lua51.dll on Windows. I
wonder if this side-effect that will last or pass?
I'm in the process of rewriting the generic script wrapper for TL on
Windows to replace the current batch s
2009/11/23 T T :
>
> OK, I'm looking into that.
After some digging through the sources and googling around I think the
problem is not with luatex's implementation but with _spawnvpe
function on Windows, which can't handle arguments with spaces (how
pathetic). So I should wri
2009/11/23 Taco Hoekwater :
>
> Let's put it this way: windows command line processing does not
> agree with my neurons, so I have stayed way from it as much as
> possible (and will continue to do so).
Yes, I know it's PITA.
>
> A good, clean patch would be welcome of course, but I myself will no
2009/11/23 Hans Hagen :
> arg = {
> "dir",
> "bar",
> '"foo bar"',
> }
>
> os.spawn(arg)
>
> works ok, so without arg[0]
Yes, but your arg[1] has no spaces in it. Try running some program
under %ProgramFiles% or other path with spaces.
Cheers,
Tomek
_
Hi,
I have encountered a problem with os.spawn(arg) on Windows. If
arg[1]='foo bar' and arg[0]=nil, then the spawned process gets 'foo'
as argv[0] and 'bar' as argv[1]. This might be expected, since
according to docs, os.spawn doesn't do any argument processing.
So I tried double quoting arg[1]='
2009/11/1 Manuel Pégourié-Gonnard :
> Hi,
>
> T T a écrit :
>> I've noticed that os.execute under texlua echos its argument to
>> stderr. This is not the behaviour under the standard lua interpreter.
>> Is it a bug or feature (and what would be the reason for it)?
Hi,
I've noticed that os.execute under texlua echos its argument to
stderr. This is not the behaviour under the standard lua interpreter.
Is it a bug or feature (and what would be the reason for it)?
Cheers,
Tomek
___
dev-luatex mailing list
dev-luatex
38 matches
Mail list logo
