> Therefore, I've now worked it into pdfroff.sh: (patch attached).
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
On Saturday 07 May 2005 11:13 pm, I wrote:
> On Saturday 07 May 2005 6:08 pm, Werner LEMBERG wrote:
> > > Attached is a small script, demonstrating a possible `searchpath'
> > > shell function. [...]
> >
> > On my Linux box it works fine.
>
> As indeed, it does on mine. It also works fine on my W
Zvezdan Petkovic wrote, quoting me:
> On Fri, May 06, 2005 at 03:51:17AM +0100, Keith Marshall wrote:
>> On Thursday 05 May 2005 7:40 pm, Zvezdan Petkovic wrote:
>>> BTW, I don't think Cygwin should be a measure of Unix compatibility.
>>
>> Possibly not; but, like it or not, Microsoft Windows has
On Saturday 07 May 2005 6:08 pm, Werner LEMBERG wrote:
> > Attached is a small script, demonstrating a possible `searchpath'
> > shell function. [...]
>
> On my Linux box it works fine.
As indeed, it does on mine. It also works fine on my Win32 box, both in the
MSYS and Cygwin environments, and
> Should I rather use option 3, [...]
No.
> Attached is a small script, demonstrating a possible `searchpath'
> shell function. [...]
On my Linux box it works fine.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/list
On Fri, May 06, 2005 at 03:51:17AM +0100, Keith Marshall wrote:
> On Thursday 05 May 2005 7:40 pm, Zvezdan Petkovic wrote:
> > BTW, I don't think Cygwin should be a measure of Unix compatibility.
>
> Possibly not; but, like it or not, Microsoft Windows has the largest user
> base of any OS on the
On Friday 06 May 2005 5:17 am, Keith Marshall wrote:
> Attached is a small script, demonstrating a possible `searchpath' shell
> function.
Drat! Forgot the attachment! Here it is now ...
searchpath.sh.gz
Description: GNU Zip compressed data
___
Grof
On Thursday 05 May 2005 10:24 am, Werner LEMBERG wrote:
> > And thanks again, for this. Unless there are any objections from
> > others, I'll investigate a solution based on option 4.
>
> I agree. What the autoconf people use we can use also.
But the truly autoconf compatible option would be my
On Thursday 05 May 2005 7:40 pm, Zvezdan Petkovic wrote:
> BTW, I don't think Cygwin should be a measure of Unix compatibility.
Possibly not; but, like it or not, Microsoft Windows has the largest user
base of any OS on the planet. For those of us who are forced, out of
corporate necessity rath
On Thu, May 05, 2005 at 10:42:13AM +0100, Keith MARSHALL wrote:
> Larry Jones wrote, quoting Zvezdan Petkovic:
> >> So the solution is to use command -v.
> >
> > Hardly -- "type" is probably more portable than "command -v" is.
> > Particularly since "command -v" is optional in the latest version o
> And thanks again, for this. Unless there are any objections from
> others, I'll investigate a solution based on option 4.
I agree. What the autoconf people use we can use also.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org
Larry Jones wrote, quoting Zvezdan Petkovic:
>> So the solution is to use command -v.
>
> Hardly -- "type" is probably more portable than "command -v" is.
> Particularly since "command -v" is optional in the latest version of
> POSIX (it's part of the User Portability Utilities option).
I agree w
Werner Lemberg wrote, quoting Larry Jones:
>> I have one last problem -- contrib/pdfmark/pdfroff.sh makes
>> extensive use of the "type" command, which is *NOT* a standard shell
>> command. I was able to work around it by changing the first line
>> from #!/bin/sh to #!/bin/bash, but it should prob
Zvezdan Petkovic writes:
>
> Well, like it or not, Korn shell was the basis for POSIX. :-)
Being as ksh is my shell of choice, I'm all for it. But given that
basis, I was surprised to find that neither "type" nor "whence" is
supported by the POSIX shell.
> So the solution is to use command -v.
On Tue, May 03, 2005 at 10:26:45AM -0400, Larry Jones wrote:
> Keith MARSHALL writes:
> >
> > Really? I didn't know that, sorry. I used `type' to check that all of the
> > necessary prerequisite programs are installed, because I understood that it
> > *was* standard in Bourne shell; I've never c
Keith MARSHALL writes:
>
> Well, I'm sorry to dispute this, but that has not been my experience. My
> first exposure to UNIX was with VentureCom's VENIX implementation, back in
> 1989. That was essentially a SVR2 implementation, and didn't have a Korn
> shell -- just a basic Bourne shell, which
Larry Jones wrote, quoting me:
>> Really? I didn't know that, sorry. I used `type' to check that all of
the
>> necessary prerequisite programs are installed, because I understood
that it
>> *was* standard in Bourne shell; I've never come across one that didn't
have
>> it, but my experience has
Keith MARSHALL writes:
>
> Really? I didn't know that, sorry. I used `type' to check that all of the
> necessary prerequisite programs are installed, because I understood that it
> *was* standard in Bourne shell; I've never come across one that didn't have
> it, but my experience has been exclus
Larry Jones wrote:
> ... I have one last problem -- contrib/pdfmark/pdfroff.sh makes
extensive
> use ofthe "type" command, which is *NOT* a standard shell command. I
was
> able to work around it by changing the first line from #!/bin/sh to
> #!/bin/bash, but it should probably be rewritten porta
> I could, but it wouldn't help -- the bug is in the system's startup
> code, which isn't part of the compiler. Fortunately, I have source
> code, so I can fix it. After setting up the environ global variable
> before running the initialization code, things work much better.
Can you prepare a s
Werner LEMBERG writes:
>
> I think this is a compiler bug. Can you try a newer compiler version?
I could, but it wouldn't help -- the bug is in the system's startup
code, which isn't part of the compiler. Fortunately, I have source
code, so I can fix it. After setting up the environ global var
> Having said that, I've subsequently realised that I omitted to test
> `pdfroff' on Cygwin. I've since done just that, and uncovered a
> problem with running in the `ash' shell, (which Cygwin uses, rather
> than `bash', in place of `sh').
>
> Here's a patch: [...]
Applied, thanks.
Werner
On Wednesday 27 April 2005 2:44 am, Keith Marshall wrote:
> ... I always test my submissions onGNU/Linux, Win32 with MinGW,
> Win32 with Cygwin ...
Having said that, I've subsequently realised that I omitted to test `pdfroff'
on Cygwin. I've since done just that, and uncovered a problem with run
Jim Reid wrote:
I very much doubt if anyone changed groff's build/install procedure
with any
intent to make it in any way Linux specific;
Fact: somebody *did* change the build/install stuff. It used to work
on BSD/OS. It had done so since at least 1996. Now it doesn't. To
some extent, this spec
Am Mittwoch, 27. April 2005 18:06 schrieb Zvezdan Petkovic:
>
> FWIW, the only reason I do not use 1.19 branch is that it doesn't work
> with gpresent. The request .PAUSE inside a pic creates a vertical move,
> and the figure ends up quite different from what it should be. :-)
> Has anything been
On Wed, Apr 27, 2005 at 09:16:33AM +0200, Werner LEMBERG wrote:
>
> > It was BSD/OS 4.2 too. I never found the time to get to the bottom
> > of the problem and abandoned updating groff on that box. Somebody
> > changed groff's build/install stuff to make it more Linux-specific,
> > breaking back
On Apr 27, 2005, at 02:44, Keith Marshall wrote:
I'm almost sorry I bothered to mention Jim Reid at all; I had
forgotten what
an irascible character he is, and I felt rather disinclined to even
grace
this drivel with a response.
Personal attacks and insults, especially unfounded ones, have no pla
> It was BSD/OS 4.2 too. I never found the time to get to the bottom
> of the problem and abandoned updating groff on that box. Somebody
> changed groff's build/install stuff to make it more Linux-specific,
> breaking backwards compatibility with the installed base.
??? This is nonsense. Norm
> It turns out that the problem is that search_path::search_path is
> called from a static constructor, but static constructors are called
> *before* the global environment pointer is set, so getenv() doesn't
> work in a static constructor. Not being a C++ expert, I have no
> idea whether this is
On Wednesday 27 April 2005 4:22 am, Jim Reid wrote:
> On Apr 27, 2005, at 02:44, Keith Marshall wrote:
> > I'm almost sorry I bothered to mention Jim Reid at all; I had
> > forgotten what
> > an irascible character he is, and I felt rather disinclined to even
> > grace
> > this drivel with a respon
On Tuesday 26 April 2005 10:19 am, Jim Reid wrote:
> >> BSD/OS 4.2.
> >
> > Ahhh. IIRC, Jim Reid had a similar problem a few months ago, also on
> > BSD.
> > Don't know what version he was using, or if he ever found a solution
> >
> > :-(
>
> It was BSD/OS 4.2 too. I never found the time to get to
BSD/OS 4.2.
Ahhh. IIRC, Jim Reid had a similar problem a few months ago, also on
BSD.
Don't know what version he was using, or if he ever found a solution
:-(
It was BSD/OS 4.2 too. I never found the time to get to the bottom of
the problem and abandoned updating groff on that box. Somebody cha
Werner LEMBERG writes:
>
> Strange. The function font::load_desc (in font.cpp) calls
> font::open_file (in fontfile.cpp) which in turn calls
> font_path.open_file, where font_path is a search_path which explicitly
> uses $GROFF_FONT_PATH. Looking into searchpatch.cpp you can see that
> search_pa
> It appears that groff doesn't pass the command line font directories
> on directly but rather sets an environment variable
> ($GROFF_FONT_PATH).
This is correct.
> That variable does seem to be set correctly for both grn and troff,
> but they don't seem to be paying any attention to it.
Stran
Keith Marshall writes:
>
> This would appear to be the bug then; strange that it only seems to show up
> on BSD, but that could be a red herring.
My guess (and it is just a guess) is that it happens everywhere but
everyone who's been building it already has the font files installed so
it hasn't
On Monday 25 April 2005 8:11 pm, Larry Jones wrote:
> Werner LEMBERG writes:
> > Perhaps you can try to use `strace' or a similar program. Then you
> > can check where the files are searched.
>
> Good idea!
>
> For reference, here's the command line from make (ktrace is BSD/OS's
> version of strac
Werner LEMBERG writes:
>
> Perhaps you can try to use `strace' or a similar program. Then you
> can check where the files are searched.
Good idea!
For reference, here's the command line from make (ktrace is BSD/OS's
version of strace):
GROFF_COMMAND_PREFIX=''; export GROFF_COMMAND_PREFIX; GR
> > Sorry, but I can't see any obvious clues in the make trace you posted.
>
> Neither can I, that's why I'm asking for help. :-)
Perhaps you can try to use `strace' or a similar program. Then you
can check where the files are searched.
Werner
__
Larry Jones wrote:
> Keith Marshall writes [quoting me]:
>>
>>> There is a DESC file in /pubic/GNU/groff/font/devps, so I'm not sure
why
>>> it's not being found.
>>
>> Presumably you have checked to ensure that it has sensible access
permissions
>> assigned? Inspected it, to ensure its conte
Keith Marshall writes [quoting me]:
>
> > There is a DESC file in /pubic/GNU/groff/font/devps, so I'm not sure why
> > it's not being found.
>
> Presumably you have checked to ensure that it has sensible access permissions
> assigned? Inspected it, to ensure its content is appropriate?
Yes, it
> The first problem was easy -- you're not allowed to have
> declarations mixed with code in C like you are in C++:
Applied, thanks.
Werner
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
On Friday 22 April 2005 10:48 pm, Larry Jones wrote:
> I'm having problems building the current CVS version of groff.
>
> The first problem was easy -- you're not allowed to have declarations
> mixed with code in C like you are in C++:
Thanks for your patch; it seems to fix a problem which I had n
I'm having problems building the current CVS version of groff.
The first problem was easy -- you're not allowed to have declarations
mixed with code in C like you are in C++:
Index: src/utils/xtotroff/xtotroff.c
===
RCS file: /cvsroo
43 matches
Mail list logo
