Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> Hadoop fs -ls behaviour compared to native ls


Copy link to this message
-
Re: Hadoop fs -ls behaviour compared to native ls
Sure. Have filed https://issues.apache.org/jira/browse/HADOOP-8788 ..
Would be interested in what comes out in the discussion.

Thanks
hemanth

On Tue, Sep 11, 2012 at 7:10 PM, Robert Evans <[EMAIL PROTECTED]> wrote:
> I think most of the rational is for backwards compatibility, but I could
> be wrong.  If you want to change it file a JIRA about it and we can
> discuss on the JIRA the merits of the change.
>
> --Bobby
>
> On 9/11/12 6:28 AM, "Hemanth Yamijala" <[EMAIL PROTECTED]> wrote:
>
>>Hi,
>>
>>hadoop fs -ls dirname
>>
>>lists entries like
>>
>>dirname/file1
>>dirname/file2
>>
>>i.e. dirname is repeated. And it takes a small second to realize that
>>there's actually no directory called dirname under dirname.
>>
>>Native ls doesn't repeat dirname when listing the output.
>>
>>I suppose the current behaviour is to handle globbing. So,
>>
>>hadoop fs -ls dirname*
>>
>>will list
>>
>>dirname1/file1
>>dirname2/file1
>>
>>which makes a little more sense. In contrast, native ls will list the
>>same as
>>
>>dirname1:
>>file1
>>
>>dirname2:
>>file1
>>
>>Is there a rationale to keep this as the listing behaviour in Hadoop ?
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB