Re: "cut" command not working as expected
On Wed, Jun 18, 2003 at 07:18:31PM +0100, David selby wrote:
> David selby wrote:
> >I need to get the first two file names from a directory ...
> >directory=$(ls -r --format=single-column)
> >cut -d' ' -f2 $directory
> >I am a relative begginer at learning bash ...
'course, this isn't exactly a bash situation -- as you found out,
$directory (a bash variable, yes) is expanded and the command "cut"
(not a bash function) sees all the file names as arguments to
operate on; if you'd sent them to cut on the standard input
(using the | pipe as suggested) it'd work just as you wanted.
> Many thanks everyone, realise my mistake with cut and file names, also
> did not realise "tail" command existed, far neater way of doing it ...
> many thanks once again
wait 'til you grok "xargs" --
find ~ -name '.*rc.bak' | xargs rename 's/rc\.bak$/rc/'
xargs expects, as its standard input, a list of file names
(beware the spaces inherent in macos and windo~1 filesystems);
its own first argument is taken to be a command to run, with
those filenames as arguments.
locate newbiedoc | grep html$ | xargs grep -i '<form'
let's break that down--
finds all documents on your system with "newbiedoc"
anywhere in the path (presuming you have done an "apt-get
install slocate") and sends them to...
| grep html$
filters file names down to those ending in html, and
passes that reduced list to...
| xargs grep -i '<form'
takes the list of html newbiedoc files and sends them to
grep, which lists all lines containing (case-irrelevant)
the string "<form".
it's similar to
grep -i '<form' `locate newbiedoc | grep html$`
(note the backticks) except that when the filename list gets
ridiculously huge, xargs breaks it up into more friendly pieces.
purty durn cool, if you ask me.
I use Debian/GNU Linux version 3.0-bunk-1;
Linux server 2.4.20-k6 #1 Mon Jan 13 23:49:14 EST 2003 i586 unknown
DEBIAN NEWBIE TIP #119 from Jonathan D. Proulx <firstname.lastname@example.org>
Having trouble RUNNING REMOTE X APPLICATIONS? You've tried "xhost
+<host>", set the DISPLAY variable on the remote session, and
checked that the "-nolisten tcp" flag is *not* being sent at X
Verify that X is really listening: "netstat -tl" will show
all listening tcp ports; you should see port 6000 open if
display :0 is listening (6001 for :1 etc.)
If it is listening, I'd start wondering about packet filtering
rules. Check ipchains or iptables...
Also see http://newbieDoc.sourceForge.net/ ...