Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Mon, 13 Jun 2011 13:51:51 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: 
 <369269424.2551.1307973111578.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <5577157.35481287784221738.JavaMail.jira@thor>
Subject: [jira] [Commented] (HDFS-1475) Want a -d flag in hadoop dfs -ls :
 Do not expand directories
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048563#comment-13048563 ] 

Daryn Sharp commented on HDFS-1475:
-----------------------------------

I have no problem marking it incompatible, but I guess I'm unclear on what constitutes an incompatible change.  The patch doesn't alter any of the pre-existing behavior -- it just adds another option.  Are enhancements considered incompatible?

BTW, the test failed because the corresponding hadoop jira is not integrated.

> Want a -d flag in hadoop dfs -ls : Do not expand directories
> ------------------------------------------------------------
>
>                 Key: HDFS-1475
>                 URL: https://issues.apache.org/jira/browse/HDFS-1475
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: hdfs client
>    Affects Versions: 0.23.0
>         Environment: any
>            Reporter: Greg Connor
>            Assignee: Daryn Sharp
>            Priority: Minor
>         Attachments: HDFS-1475.patch
>
>
> I would really love it if dfs -ls had a -d flag, like unix ls -d, which would list the directories matching the name or pattern but *not* their contents.
> Current behavior is to expand every matching dir and list its contents, which is awkward if I just want to see the matching dirs themselves (and their permissions).  Worse, if a directory exists but is empty, -ls simply returns no output at all, which is unhelpful.  
> So far we have used some ugly workarounds to this in various scripts, such as
>   -ls /path/to |grep dir   # wasteful, and problematic if "dir" is a substring of the path
>   -stat /path/to/dir "Exists"  # stat has no way to get back the full path, sadly
>   -count /path/to/dir  # works but is probably overkill.
> Really there is no reliable replacement for ls -d -- the above hacks will work but only for certain isolated contexts.  (I'm not a java programmer, or else I would probably submit a patch for this, or make my own jar file to do this since I need it a lot.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira