Bug#489943: [tex-live] Bug#489943: texlive-base-bin: mktexpk does not work in directories containing spaces

2008-10-31 Thread Hilmar Preusse
tags 489943 + fixed-upstream
stop

On 25.10.08 Jan Hudec ([EMAIL PROTECTED]) wrote:

Hi,

 So I think it can be closed when the change accepted upstream hits
 debian.

 [This is the more important change:]
   
-cd $PKDESTDIR || exit 1
+cd $PKDESTDIR || exit 1
   
   That change was already made.
 
This patch is already in TL 2008. I can't check bin/win32/mktexpk.exe
;-), but I guess it has the change too.

Tagging this bug as fixed in upstream, we'll close it when TL 2008
hits Debian.

H.
-- 
sigmentation fault



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489943: [tex-live] Bug#489943: texlive-base-bin: mktexpk does not work in directories containing spaces

2008-10-25 Thread Hilmar Preusse
On 09.07.08 Karl Berry ([EMAIL PROTECTED]) wrote:

Hi all,

I'm just doing a full quote.

The submitter requested some changes. One was accepted but upstream,
the others not. Jan, is this fine with you. Can we mark that bug
fixed in upstream and close it as soon as that single change hits
Debian?

Thanks,
  Hilmar

 Thanks for the report, but ...
 
  However I also noticed use of echo+sed dirname replacement (with comment
  can't rely on dirname -- basename was relied on on the next line 
 though),
 
 Well, that's because basename can be relied on :).
 
  which would have problems with spaces at the end (backquote expansion 
 eats
  them) and backslashes in some shells (the rules for backslash 
 processing in
  echo differ from shell to shell). So my patch additionally includes
 
 I am not surprised that there are failures with names containing spaces,
 let alone backslashes.  And since we want to move away from shell
 scripts in general (- texlua, so we can run the same code on Windows),
 I doubt it's worth anyone's time to do a in-depth exegesis of all the
 failures.
 
  -PKDESTDIR=`echo $PKDEST | sed 's%/[^/][^/]*$%%'` # can't rely on 
 dirname
 
 I am not aware of any way to improve on the portability of this
 construct.  POSIX is certainly not the answer.  Something to take up on
 the autoconf list if you really want to.
 
  -cd $PKDESTDIR || exit 1
  +cd $PKDESTDIR || exit 1
 
 That change was already made.
 

-- 
sigmentation fault



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489943: [tex-live] Bug#489943: texlive-base-bin: mktexpk does not work in directories containing spaces

2008-10-25 Thread Jan Hudec
On Sat, Oct 25, 2008 at 08:27:28 +0200, Hilmar Preusse wrote:
 On 09.07.08 Karl Berry ([EMAIL PROTECTED]) wrote:
 
 Hi all,
 
 I'm just doing a full quote.
 
 The submitter requested some changes. One was accepted but upstream,
 the others not. Jan, is this fine with you. Can we mark that bug
 fixed in upstream and close it as soon as that single change hits
 Debian?
 
 Thanks,
   Hilmar

Yes. The other change is a clean-up for rare cases and if there is some
supported shell that does not support ${var%pattern} and ${var#pattern}
substitutions, than I guess there's nothing that can be done with that case.

So I think it can be closed when the change accepted upstream hits debian.
Thanks,

Jan

[This is the more important change:]
  
   -cd $PKDESTDIR || exit 1
   +cd $PKDESTDIR || exit 1
  
  That change was already made.

-- 
 Jan 'Bulb' Hudec [EMAIL 
PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489943: [tex-live] Bug#489943: texlive-base-bin: mktexpk does not work in directories containing spaces

2008-07-08 Thread Vladimir Volovich
NP == Norbert Preining writes:

  So my patch additionally includes a replacement of those two
  statements with ${var##pattern} and ${var%pattern} expansions. These
  expansions are POSIX and should thus be reasonably portable.

note that on Solaris, /bin/sh is not a POSIX shell (there is a POSIX
shell at /usr/xpg4/bin/sh).

$ ZZZ=/aa/bb/cc/dd
$ echo ${ZZZ%/*}
bad substitution
$ echo ${ZZZ##*/}
bad substitution

Best,
v.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489943: [tex-live] Bug#489943: texlive-base-bin: mktexpk does not work in directories containing spaces

2008-07-08 Thread Karl Berry
  So my patch additionally includes a replacement of those two
  statements with ${var##pattern} and ${var%pattern} expansions. These
  expansions are POSIX and should thus be reasonably portable.

Sorry, POSIX introduced many incompatible shell constructs (and command
line options, and ...) that must be avoided for anything that actually
needs to be portable.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#489943: [tex-live] Bug#489943: texlive-base-bin: mktexpk does not work in directories containing spaces

2008-07-08 Thread Karl Berry
Thanks for the report, but ...

 However I also noticed use of echo+sed dirname replacement (with comment
 can't rely on dirname -- basename was relied on on the next line 
though),

Well, that's because basename can be relied on :).

 which would have problems with spaces at the end (backquote expansion eats
 them) and backslashes in some shells (the rules for backslash processing 
in
 echo differ from shell to shell). So my patch additionally includes

I am not surprised that there are failures with names containing spaces,
let alone backslashes.  And since we want to move away from shell
scripts in general (- texlua, so we can run the same code on Windows),
I doubt it's worth anyone's time to do a in-depth exegesis of all the
failures.

 -PKDESTDIR=`echo $PKDEST | sed 's%/[^/][^/]*$%%'` # can't rely on 
dirname

I am not aware of any way to improve on the portability of this
construct.  POSIX is certainly not the answer.  Something to take up on
the autoconf list if you really want to.

 -cd $PKDESTDIR || exit 1
 +cd $PKDESTDIR || exit 1

That change was already made.

Best,
karl



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]