On Wed, 30 Aug 2017 18:50:26 +0200, Jeremie Courreges-Anglas wrote:
> On Wed, Aug 30 2017, "Todd C. Miller" wrote:
> > Looks good to me. Do we want to document this as an extension in
> > the manual? We're not very good about documenting extensions to
> > traditional
On Wed, Aug 30 2017, "Todd C. Miller" wrote:
> Looks good to me. Do we want to document this as an extension in
> the manual? We're not very good about documenting extensions to
> traditional ksh behavior.
I'm not against this but I'm not thrilled either. If anyone
Looks good to me. Do we want to document this as an extension in
the manual? We're not very good about documenting extensions to
traditional ksh behavior.
- todd
Yes, please!
Il 30 agosto 2017 13:04:02 CEST, Jeremie Courreges-Anglas ha
scritto:
>
>This implements a feature I miss from bash. What I care about:
>- not clog the history with repeated commands
>- easily prevent some commands to go in the history
>
>The diff below implements
Hi Jeremie,
Am 30.08.2017 13:04 schrieb Jeremie Courreges-Anglas:
This implements a feature I miss from bash. What I care about:
- not clog the history with repeated commands
- easily prevent some commands to go in the history
The diff below implements HISTCONTROL for this, user-facing
This implements a feature I miss from bash. What I care about:
- not clog the history with repeated commands
- easily prevent some commands to go in the history
The diff below implements HISTCONTROL for this, user-facing behavior
based on bash. The default ksh behavior doesn't change.
I did