aws s3 ls inconsistent file names with/without --recursive

[asieira]

When aws s3 ls is executed on awscli/1.2.11 without --recursive, the resulting files and prefixes are listed as relative to the given path:

| => aws s3 ls s3://testbucket/dir1/dir2/dir3/
                           PRE dir4/
2013-09-09 20:33:25    2865280 file1

However, when --recursive is added to the same path, the resulting files are listed as the entire prefix (full path sans s3://<bucket name>):

| => aws s3 ls s3://testbucket/dir1/dir2/dir3/ --recursive
2013-09-09 20:33:25    2865280 dir1/dir2/dir3/file1
2013-09-09 20:33:26    5117249 dir1/dir2/dir3/dir4/file2

See, if the behavior was consistent and relative paths to the listed prefix were always used, the second output should have been as follows:

| => aws s3 ls s3://testbucket/dir1/dir2/dir3/ --recursive
2013-09-09 20:33:25    2865280 file1
2013-09-09 20:33:26    5117249 dir4/file2

Perhaps new options --relative and --absolute could be added to aws s3 ls to choose which behavior we want, or at the very least both are made to function in a similar fashion. I vote for relative paths on both cases.

[jamesls]

Changing this to be a feature request for the --relative option. I think the default behavior has been around long enough and has some useful properties (having the full key name so it can be piped into other operations that require the full s3 key name).

[asieira]

👍

[nkadel-skyhook]

Document this in the "aws s3 ls" command, please, or ideally make it optional. It very frustrating to sync, and review, a complex filesystem and have to reparse the output for comparison between local and remote content. And it's more complex because of the undocumented stripping of the bucket name from the output.

[ASayre]

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

[jamesls]

Based on community feedback, we have decided to return feature requests to GitHub issues.

[github-actions]

Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. Because it has been longer than one year since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment to prevent automatic closure, or if the issue is already closed, please feel free to reopen it.

[asieira]

This is still an issue in version 2.0.48, so IMHO this issue should not be deleted.

[fatmanmclone90]

Does anyone have a workaround for this? I need to find a file using a recursive ls and then download with cp

[tim-finnigan]

It looks like a PR was created for this and merged (#3641).

But I can also still reproduce this in v2:

It looks like somehow those changes did not actually get integrated into v2. We need more investigation into why this happened and decide where to go from there.

We also have #3645 open for consideration of an --absolute parameter. I think that request was created under the assumption that the PR mentioned above was integrated and a relative path would be returned by default when --recursive is used. At this point it might be best to maintain the current behavior by default but just add a --relative flag as originally requested here.

[github-actions]

Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or upvote with a reaction on the initial post to prevent automatic closure. If the issue is already closed, please feel free to open a new one.