# IPFS files API: plans for additional commands? **URL:** \ **Category:** Help\ **Created:** [June 24, 2017, 6:36pm UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670 "2017-06-24T18:36:27Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![JayBrown](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jaybrown/32/107_2.png) [@JayBrown](https://discuss.ipfs.tech/u/JayBrown)\ **Post date:** [June 24, 2017, 6:36pm UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670/1 "2017-06-24T18:36:28Z")
Are there plans to add additional Unix-style commands to the `ipfs files` API? I’m primarily thinking about `ipfs files cd /folder/subfolder`, which would mean that `ipfs files ls` would then list the contents of the subfolder, not of the root directory. Vice versa, `ipfs files cd /` would bring you back to root. Accordingly, it would then also need `ipfs files pwd`. And is there a reason why it’s called `ipfs files read`, while the standard command is `ipfs cat`? ---
**Author:** ![JayBrown](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jaybrown/32/107_2.png) [@JayBrown](https://discuss.ipfs.tech/u/JayBrown)\ **Post date:** [July 1, 2017, 12:27pm UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670/2 "2017-07-01T12:27:52Z")
Another thing we’d probably need is wildcards, e.g. `ipfs files rm /path/foo*`, including stuff like `^bar`, `baz$` etc. ---
**Author:** ![JayBrown](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jaybrown/32/107_2.png) [@JayBrown](https://discuss.ipfs.tech/u/JayBrown)\ **Post date:** [August 30, 2017, 8:38am UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670/3 "2017-08-30T08:38:41Z")
Another option would be to recurse the MFS, i.e. something like `ipfs files ls -l -r --files --maxdepth 2 /dir1 /dir2`. Options could be: (a) omit file listings, i.e. show directories only; (b) vice versa); © show all objects; (d) maximum recurse depth with 0=full, 1=root-only, 2=sublevel1 etc. go-ipfs would then have to output the full MFS path, not just the basename. I have a shell alias that does that (see below), but it would be awesome to have it implemented in go-ipfs. [https://github.com/JayBrown/Tools/blob/master/Aliases/ipfrec](https://github.com/JayBrown/Tools/blob/master/Aliases/ipfrec) ![snapshot](https://us1.discourse-cdn.com/flex020/uploads/ipfs1/original/1X/650183b33ec94dbd685a610e2b93a7a92e1b1435.jpg) ---
**Author:** ![JayBrown](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jaybrown/32/107_2.png) [@JayBrown](https://discuss.ipfs.tech/u/JayBrown)\ **Post date:** [August 31, 2017, 8:02am UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670/4 "2017-08-31T08:02:40Z")
Another thought: in relation to the above `ipfs files rm` and `ipfs files rm -r` it would be great to have the option to auto-unpin all of the objects removed from the MFS, e.g. `ipfs files rm -r -u /MFSpath`. It shouldn’t unpin objects that have a copy elsewhere in the MFS. For that you should need a force-unpin option, e.g. `ipfs files rm -r -u -f /MFSPath`, which would then remove the other copies from the MFS as well. ---
**Author:** ![josselinchevalay](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/josselinchevalay/32/3078_2.png) [@josselinchevalay](https://discuss.ipfs.tech/u/josselinchevalay)\ **Post date:** [August 31, 2017, 8:26am UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670/5 "2017-08-31T08:26:12Z")
Hey Jay i’m not sure but i think we cannot rm in IPFS it’s no sense with (Web permanent and decentralize) no ? Regards ---
**Author:** ![JayBrown](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jaybrown/32/107_2.png) [@JayBrown](https://discuss.ipfs.tech/u/JayBrown)\ **Post date:** [August 31, 2017, 8:44am UTC](https://discuss.ipfs.tech/t/ipfs-files-api-plans-for-additional-commands/670/6 "2017-08-31T08:44:46Z")
Yeah, you can’t delete objects from the network that are already distributed. But this is about removing objects from the MFS (mutable filesystem) of the local node. The command already exists; see here: [https://ipfs.io/docs/commands/#ipfs-files-rm](https://ipfs.io/docs/commands/#ipfs-files-rm) Currently, objects stay pinned to your node, if you remove them from the MFS, which is why you need to perform an additional `ipfs pin rm` command. Ergo the idea to also have an option to (force) unpin the object as well, when running `ipfs files rm`, not just remove it from the MFS.