I agree in general, and will stay silent after this email (I already have a useful modification I can use), but none of the tools mentioned can perform this task in a well thought out and general reusable case.
My counterpoints are: - Most of the time a hard character limit is a hard character limit. Extending lines would certainly be fine in my case as it was simply a desire to remain consistent with previous work. But I know with many code bases it's a hard requirement so ensuring shorter lines would be of great usefulness there. - Having the functionality be a part of fold would allow it to be very general and avoid needing to write a specialized or very lengthy script for each character involved (backslash is a special case, and so are some chars that require extra formatting magic to work in the shell script so it can't be generalized very easily) - The approach suggested by you is fuzzy and not exacting. The "current" line would be truncated, but the next would be extended. So if you were looking for well formatted code, then you would need to use conditional shell magic to handing re-adjusting the line length of following lines after shuffling the "special char" to the next line. As far as I can see you cannot reliably handle special characters, and exacting length with reliable fallback behavior (mostly 80 char with 79 fallback; mostly 80 char with 81 fallback), without an inordinate amount shell scripting magic. I fully appreciate your charge of protecting the coreutils code base but also believe this behavior is well worth the extra code base. Anyways, this is the last time you'll hear from me on this topic if you further disagree, and I will happily continue on my merry way:) ~Kyle On Mon, May 11, 2015 at 10:59 AM, Pádraig Brady <[email protected]> wrote: > On 09/05/15 18:16, RabidCicada wrote: > > Function: > > Fold on width boundary avoiding breaking (don't break) on the target > char by folding one char early or one char late. > > > > Syntax: > > Example: 'fold -d\\- -w30' > > > > Flag Usage: > > -d<chartoavoid><minus sign for folding early plus sign for folding late> > > default behavior is to fold early (break lines to less than width) > > > > > > Motivating Example: > > I was putting together a shell script to break a long string into pieces > for a header file. In particular I was taking a human formatted xmlfile > and wanting to split it into multiple lines and adhere to the typical 80 > char limit. The problem was that there are escaped quotes within the xml. > Fold, in general, seemed like the appropriate tool, but I couldn't find a > reasonable way to split at 80 but avoid breaking directly following the '\'. > > > > Bad split string result: > > "tart</property><property name=\"margin_bottom\">6</property><property > name=\" > > ""hexpand\">True</property><property > name=\"label\">[title]</property><attrib" > > This results in the final quote being escaped and messing up the header > file. > > > > Good split string result: > > "tart</property><property name=\"margin_bottom\">6</property><property > name=" > > "\"hexpand\">True</property><property > name=\"label\">[title]</property><attri" > > > > It splits the string one char early to avoid the '\' wreaking havoc. > > > > > > My final shell script, using my custom modified fold, looks like this: > > sed 's/^[[:space:]]*//' $1 | sed 's/[[:space:]]*$//' | sed -z 's/\n//g' > | sed 's/"/\\"/g' | fold -w76 -d\\ | sed 's/^/ "/g' | sed 's/$/"/g' > $2 > > > > It takes the regular xml file, chomps off extraneous whitespace (seds 1 > & 2), then removes all newlines to condense into single blob(sed 3), then > escapes all inline quotes (sed 4), then folds using my special flag to > avoid the escape characters, then tacks on the opening and closing quotes > and spaces for the header file string (seds 5 & 6). > > > > I looked all around and I couldn't find a tool that could fold/split, > but avoid splitting on chosen char. I thought I would find one...but > alas...none. > > > > I have this implemented and usage messages updated but don't have other > documentation and tasking in order yet. If this would be an accepted > feature, I would be happy to finalize all the housework to submit patches > with full documentation, texi, etc. I certainly see it being useful for > other similar tasks where a key char should not be at the fold barrier. > > > > I looked at the rejected features idea and don't see ANY listed for > fold:). Maybe it can get some love? Anyone support or object to the idea? > > Thanks for taking the time to read the rejected ideas. > In general, given the overlap between pr, fmt, and fold > there is a high barrier to adding new options. > In your case you could change the processing steps > after the fold to: > > ... | fold in -w76 | sed 's/\\$//; s/^"/\\"/; s/^/"/; s/$/"/' > > That would bump lines slightly longer, and assumes > no other \ in the data, but you get the idea. > > cheers, > Pádraig. > -- "Ambush!?....I just ambushed you with a cup of coffee" -CIA agent (RONIN)
