commit 8573f94c2f3ba17ec5d7dd123338c14a550e57e6
Author: Vladimir Iakovlev <nvbn.rm@gmail.com>
Date: Fri Feb 23 20:45:01 2018 +0100
#785: Remove functional test
commit 5484576d6e3ef4a53d69860ef953bb48037e8a72
Merge: a36a8b4 f59aa93
Author: Vladimir Iakovlev <nvbn.rm@gmail.com>
Date: Fri Feb 23 20:44:20 2018 +0100
Merge branch 'master' of https://github.com/alexbarcelo/thefuck into alexbarcelo-master
commit f59aa931c3d76b40b2078cf2926b239dc0798b74
Author: Alex Barcelo <alex.barcelo@gmail.com>
Date: Fri Feb 16 23:43:43 2018 +0100
rewritten match + fish output check for cd_* rules
commit 150ecee00ff3354a2b952a55565d08ed26161273
Author: Alex Barcelo <alex.barcelo@gmail.com>
Date: Fri Feb 16 23:43:19 2018 +0100
Adding unittest for cd_correction (with extra fish test case, also for cd_mkdir)
commit e73dd3f6d108fa081da891c61f91968afd9c5518
Author: Alex Barcelo <alex.barcelo@gmail.com>
Date: Fri Feb 16 22:48:22 2018 +0100
adding functional test for cd_correction rule
commit d1dbbb57d96df06cf0608f2d4325abf265498aa6
Author: Alex Barcelo <alex@betarho.net>
Date: Fri Feb 16 12:21:33 2018 +0100
Include root (start with /) case
* apt_list_upgradable: Prepend sudo to suggestion if used in command
* Add apt_upgrade rule
This suggests `apt upgrade` after `apt list --upgradable` if there are
packages to upgrade. It pairs well with the `apt_list_upgradable` rule,
which suggests `apt list --upgradable` after `apt update` if there are
packages to upgrade.
* Add apt_upgrade rule to README
* Drop Python 3.3 Support
It's reached end-of-life, and our dependencies have started to drop it.
See https://github.com/nvbn/thefuck/pull/744#issuecomment-353244371
* Revert "Use pytest<3.3 to fix Python 3.3 tests (#746)"
This reverts commit f966ecd4f5b8221ee15e843f5ec287e1f7cca940.
This fixes https://github.com/nvbn/thefuck/issues/632
This uses `script_parts` instead of `script.startswith`
to let it work even if there's extra spaces in the command, e.g.
git checkout unknown
See https://github.com/nvbn/thefuck/pull/744 for context.
I'm personally okay with dropping Python 3.3 support,
but I'd like to at least get the tests working while we decide on that.
Unfortunately, I didn't catch these issues while reviewing #702.
After looking more closely at `php` options, `-S` requires additional
arguments (<address>:<port>) and `-s` may produce output if used that
way. So, matching ` -s ` seems to be better.
Also, `@for_app('php')` already asserts the presence of `php ` in the
command script. Matching `php -s` prevents the rule from fixing commands
like `php -t public -s 0.0.0.0:8080`.
