Re: [SLUG] basename files and paths with embedded spaces

2003-08-14 Thread Ian Wienand
On Thu, Aug 07, 2003 at 09:52:04AM +1000, Stuart Guthrie wrote:
 Bug or feature:
 I'm wondering why the standard basename and dirname commands in gnu do 
 not handle spaces in file names and paths.

They do :

[EMAIL PROTECTED] ianw]$ basename /this is/a path/with / spaces
 spaces

are you quoting correctly?

-i
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


Re: [SLUG] basename files and paths with embedded spaces

2003-08-14 Thread Jan Schmidt
quote who=Stuart Guthrie

 Bug or feature:
 I'm wondering why the standard basename and dirname commands in gnu do 
 not handle spaces in file names and paths. I guess there is a good 
 reason why we need to code around it - ie it would break lots of other 
 stuff to fix it.

... it works for me. As always with names with spaces though, you need to
escape to prevent the shell parsing the string into separate arguments:

basename '/spacey tmp/test file.txt' .txt
test file
dirname '/spacey tmp/test file.txt'
/spacey tmp

 Question:
 Is there any /bin/sh script out there that handles this? Googling has so 
 far been fruitless.  Looks like I might have to bsh it.

Make sure your variable quoting is correct.

J.
-- 
Jan Schmidt  [EMAIL PROTECTED]

Open Source Software: Free as in Free Speech, not Free Beer
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


Re: [SLUG] basename files and paths with embedded spaces

2003-08-14 Thread Terry Collins
Stuart Guthrie wrote:
 
 Bug or feature:
 I'm wondering why the standard basename and dirname commands in gnu do
 not handle spaces in file names and paths. I guess there is a good
 reason why we need to code around it - ie it would break lots of other
 stuff to fix it.

You must be new

easiest is somecommand file name with spaces -someoption

Far easier than having to decided which of the following is correct

mv thisfile there
mv thisfile  there
mv thisfile   there
mv  thisfile there
mv  thisfile  there
..
-- 
   Terry Collins {:-)}}} email: terryc at woa.com.au  www:
http://www.woa.com.au  
   Wombat Outdoor Adventures Bicycles, Computers, GIS, Printing,
Publishing

 People without trees are like fish without clean water
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


Re: [SLUG] basename files and paths with embedded spaces

2003-08-14 Thread Angus Lees
At Thu, 7 Aug 2003 23:45:58 +1000, Matthew Hannigan wrote:
 This behaviour has long been considered a bug
 in the shell by many.  But unfortunately it's 
 too late to change it for the standard shell.

zsh by default does the right thing, which of course irritates the
hell out of everyone who expects it to do the legacy thing.

For reference, to expand a zsh variable and re-break it up into words
(as normal bourne shell does), you have to do ${=variable_name}.

There are standard ways of making bourne shell scripts immune to
spaces in filenames, they basically revolve around using
$variable_name (with the quotes) everywhere and $@ (with the
quotes) if you want to pass all args through to some other command.

-- 
 - Gus
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


Re: [SLUG] basename files and paths with embedded spaces

2003-08-14 Thread John McQuillen
On Thu, 2003-08-07 at 09:58, Ian Wienand wrote:
 On Thu, Aug 07, 2003 at 09:52:04AM +1000, Stuart Guthrie wrote:
  Bug or feature:
  I'm wondering why the standard basename and dirname commands in gnu do 
  not handle spaces in file names and paths.
 
 They do :
 
 [EMAIL PROTECTED] ianw]$ basename /this is/a path/with / spaces
  spaces
 
 are you quoting correctly?
 

or:

[EMAIL PROTECTED] dementis]$ basename this\ is/a\ path/with\ spaces/
with spaces

John...
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


Re: [SLUG] basename files and paths with embedded spaces

2003-08-10 Thread mlh

This behaviour has long been considered a bug
in the shell by many.  But unfortunately it's 
too late to change it for the standard shell.

Apparently in plan9 (unix's successor) the
standard shell 'rc' does the right thing.

You can get a rc workalike called 'es' for Unix/linux.

http://people.cs.uchicago.edu/~csdayton/software/


Matt
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


[SLUG] basename files and paths with embedded spaces

2003-08-08 Thread Stuart Guthrie
Bug or feature:
I'm wondering why the standard basename and dirname commands in gnu do 
not handle spaces in file names and paths. I guess there is a good 
reason why we need to code around it - ie it would break lots of other 
stuff to fix it.

Question:
Is there any /bin/sh script out there that handles this? Googling has so 
far been fruitless.  Looks like I might have to bsh it.

Stu

--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


Re: [SLUG] basename files and paths with embedded spaces

2003-08-07 Thread Stuart Guthrie
Yes it was a quoting issue. Tired and sick (in that order).

FWIW here is a script that if you use gnome nautilus will create a pdf 
of  a multi page tiff into the same dir. ie place script in 
~/.gnome2/nautilus-scripts :

#!/bin/sh
BASENAME=`basename $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS`
DIR=`dirname $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS`
cp $DIR/$BASENAME /tmp/$BASENAME
cd /tmp
rm prefix*.tif
tiffsplit $BASENAME prefix
tiff2ps prefix*.tif  $1.ps
ps2pdf $1.ps $1.pdf
rm $1.ps
mv $1.pdf ${DIR}/.
xpdf ${DIR}/${1}.pdf
Takes about 12 secs for a 2.2Mb tiff to display in pdf.

Thanks to those who replied.

Stu

--
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug


RE: [SLUG] basename files and paths with embedded spaces

2003-08-06 Thread Rowling, Jill
Hmm I'd say mostly because it used not to have to.
Indeed it would break quite a few things.
The standard separator for command line parameters, for example, is the
space character.
The usual way of parsing is to break up the parameters based on the number
of spaces so things like $1 $2 $3 work in shell scripts.
I suspect in order to stay posix compliant (i.e. not break earlier software)
you would have to either use quoted strings when referring to files with
spaces, or do what MacOSX does and use the backslash symbol before the
space.
While we are on that topic, I would imagine if you supported UTF8 / i8n then
the space problem kind of goes away because all filenames then become
somewhat unprintable.

Regards,

Jill. 

-Original Message-
From: Stuart Guthrie [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 7 August 2003 9:52 AM
To: [EMAIL PROTECTED]
Subject: [SLUG] basename  files and paths with embedded spaces


Bug or feature:
I'm wondering why the standard basename and dirname commands in gnu do 
not handle spaces in file names and paths. I guess there is a good 
reason why we need to code around it - ie it would break lots of other 
stuff to fix it.

Question:
Is there any /bin/sh script out there that handles this? Googling has so 
far been fruitless.  Looks like I might have to bsh it.


Stu


-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

--
IMPORTANT NOTICES
This email (including any documents referred to in, or attached, to this
email) may contain information that is personal, confidential or the subject
of copyright or other proprietary rights in favour of Aristocrat, its
affiliates or third parties. This email is intended only for the named
addressee. Any privacy, confidence, copyright or other proprietary rights in
favour of Aristocrat, its affiliates or third parties, is not lost because
this email was sent to you by mistake.

If you received this email by mistake you should: (i) not copy, disclose,
distribute or otherwise use it, or its contents, without the consent of
Aristocrat or the owner of the relevant rights; (ii) let us know of the
mistake by reply email or by telephone (+61 2 9413 6300); and (iii) delete
it from your system and destroy all copies.

Any personal information contained in this email must be handled in
accordance with applicable privacy laws.

Electronic and internet communications can be interfered with or affected by
viruses and other defects. As a result, such communications may not be
successfully received or, if received, may cause interference with the
integrity of receiving, processing or related systems (including hardware,
software and data or information on, or using, that hardware or software).
Aristocrat gives no assurances in relation to these matters.

If you have any doubts about the veracity or integrity of any electronic
communication we appear to have sent you, please call +61 2 9413 6300 for
clarification.
-- 
SLUG - Sydney Linux User's Group - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug