@jcberquist (or anyone else who might know), I'm not really sure what the best channel is for this so here goes, I'm having an issue with cfformat between Windows and Ubuntu. The app in question is mostly developed by people on Windows and cfformat is working there (using custom .cfformat.json file in the root of the app). All files are formatted and a format --check says everything is in order (on Windows). I set up a github action to run cfformat on pushes and, there, it claims all files need formatting. After some digging, it looks like Ubuntu is ignoring the "tab_indent: true" setting and expects all my tab indents to be 8 spaces. If I turn the setting off, then windows and ubuntu act the same but, of course, it means all those tabs become spaces. ...which I guess is the "fix" if there is no other trick to get around it. Do you know of any settings magic to get tab_indent: true working as expected on Ubuntu? Both Windows and Ubuntu are running commandbox 5.8 and cfformat 0.19.0

i would check for the existence of special line characters using vim or vi.

there are no special or hidden characters

1. Ugh hit enter.. bump.. anyrate in vi or vin you can use : set tabstop=4 and avoid any special characters using set shiftwidth=4 and then bind it all in the vimrc

most people in this code are using Windows

well you can always take their files, implicitly strip any Windows characters out.

it doesn't seem to be related to any special characters... just seems to be that tab_indent: true cfformat setting is ignored on Ubuntu

Ubuntu ignores a lot of standards for its own unique design flaws, I would give @bdw429s a shout-out as CommandBox is his baby. Myabe he has a "fix" or at least can has lost more sleep staring at that source than most.

I talked to Brad already when I thought it was possibly an issue inside commandbox-actions but eventually came to the conclusion it was cfformat specifically. That's why I posted here and tagged the author.

My "belief" is that that tag eventually gets traced back to a base java function that relies upon the OS level.. Digging into this , maybe this is installed someplace... https://manpages.ubuntu.com/manpages/trusty/man1/astyle.1.html

I seriously doubt that is installed in a base ubuntu-latest docker image since it is not a base ubuntu package (i.e., you have to install it after the fact)

if you didnt build it, its worth spending half a second to just check. Plus is this issue with all LINUX / UNIX versions or just your install.

I've not checked any other distros. commandbox-actions recommendation is ubuntu-latest

instead of to run the binary, you should just try to see if it exists.. "dpkg -L astyle"

dpkg-query: package 'astyle' is not installed

on one of the files you are checking, first run cffeed against just that file and then see if its utf-8 encoded with file -i nameofyourfile

@bhartsfield Can you say more about how changing the

tab_indent

setting gets everything to work? I would not expect that setting to cause differences between Windows and Linux. My first thought would definitely be line endings, so I would start by checking that. The

newline

setting in

.cfformat.json

is set to

os

by default which means it uses

\n

on linux and mac, and

\r\n

on windows. Depending on how you have set up your git repository, this can cause issues when comparing formatting.

the settings is \r\n in .cfformat.json. And what I mean by that is that removing tab_indent: true or setting it to false (and then cfformatting to change all tab indents to spaces) results in ubuntu and windows giving the same passing results.

Thanks for confirming it isn't the line endings. With your last screenshot, is that what you get (8 spaces) if you actually format the file under WSL?

oddly enough, no, cfformatting in WSL leaves the tabs but changes the line endings to just LF

what do you get if you run the check with

--verbose

?

image.png

Where is the

.cfformat.json

file relative to the component? Possibly it isn't picking up that file and is using the cfformat defaults?

its in the same directory (root) where the component is and from where the command runs

In the example you gave above, in the

testformat

directory, I would expect the newlines to be set to

\n

as you haven't (in that simple example) overwritten the

newline

setting in

.cfformat.json

. Is there any other

.cfformat.json

file at play when you ran that? You can verify the actual settings used by running

cfformat settings show

in that directory, and it should show you the full set of settings used, and the setting files it used.

It claims the correct file and outputs a lot more than what's actually in the file (guessing it is merging my settings with some defaults to show those settings?)

/github/workspace/app/.cfformat.json
{
    "alignment.consecutive.assignments":true,
    "alignment.consecutive.params":true,
    "alignment.consecutive.properties":true,
    "alignment.doc_comments":false,
    "array.empty_padding":false,
    "array.multiline.comma_dangle":false,
    "array.multiline.element_count":2,
    "array.multiline.leading_comma":false,
    "array.multiline.leading_comma.padding":true,
    "array.multiline.min_length":50,
    "array.padding":true,
    "binary_operators.newline_indent":false,
    "binary_operators.padding":true,
    "brackets.padding":false,
    "comment.asterisks":"align",
    "for_loop_semicolons.padding":true,
    "function_anonymous.empty_padding":false,
    "function_anonymous.group_to_block_spacing":"compact",
    "function_anonymous.multiline.comma_dangle":false,
    "function_anonymous.multiline.element_count":3,
    "function_anonymous.multiline.leading_comma":false,
    "function_anonymous.multiline.leading_comma.padding":true,
    "function_anonymous.multiline.min_length":50,
    "function_anonymous.padding":true,
    "function_anonymous.spacing_to_group":false,
    "function_call.casing.builtin":"cfdocs",
    "function_call.casing.userdefined":"camel",
    "function_call.empty_padding":false,
    "function_call.multiline.comma_dangle":false,
    "function_call.multiline.element_count":4,
    "function_call.multiline.leading_comma":false,
    "function_call.multiline.leading_comma.padding":true,
    "function_call.multiline.min_length":150,
    "function_call.padding":true,
    "function_declaration.empty_padding":false,
    "function_declaration.group_to_block_spacing":"compact",
    "function_declaration.multiline.comma_dangle":false,
    "function_declaration.multiline.element_count":3,
    "function_declaration.multiline.leading_comma":false,
    "function_declaration.multiline.leading_comma.padding":true,
    "function_declaration.multiline.min_length":50,
    "function_declaration.padding":true,
    "function_declaration.spacing_to_group":false,
    "indent_size":4,
    "keywords.block_to_keyword_spacing":"spaced",
    "keywords.empty_group_spacing":false,
    "keywords.group_to_block_spacing":"spaced",
    "keywords.padding_inside_group":true,
    "keywords.spacing_to_block":"spaced",
    "keywords.spacing_to_group":true,
    "max_columns":150,
    "metadata.key_value.padding":false,
    "metadata.multiline.element_count":5,
    "metadata.multiline.min_length":50,
    "method_call.chain.multiline":4,
    "newline":"\r\n",
    "param.key_value.padding":false,
    "param.multiline.element_count":4,
    "param.multiline.min_length":40,
    "parentheses.padding":true,
    "property.key_value.padding":false,
    "property.multiline.element_count":5,
    "property.multiline.min_length":30,
    "strings.attributes.quote":"double",
    "strings.convertNestedQuotes":true,
    "strings.quote":"double",
    "struct.empty_padding":false,
    "struct.multiline.comma_dangle":false,
    "struct.multiline.element_count":5,
    "struct.multiline.leading_comma":false,
    "struct.multiline.leading_comma.padding":true,
    "struct.multiline.min_length":60,
    "struct.padding":true,
    "struct.quote_keys":true,
    "struct.separator":": ",
    "tab_indent":true,
    "tags.lowercase":true
}

Did you verify what setting files were reported as in use for WSL and powershell? It looks to me like the WSL settings are all the defaults.

it was the same .cfformat.json file in both cases

I think at this point I am confused between your simplified test scenario, and your actual git repository where the github code action is running. In your simplified test scenario, my impression is that you have the test component, with a

.cfformat.json

file that only changes the

tab_indent

setting. Then you are

cfformat check

ing that via WSL, and via PowerShell on Windows. Am I misunderstanding your simplified test? If my understanding is correct, then the default

newline

setting of

os

is active, and so I would expect either the WSL or the Windows check to fail, depending on which line endings the file actually has.

Setting the newline to "os" and formatting lets WSL verify all files but powershell fails them all. Setting it to \n lets both validate all files. Starting to look like that's what I'm, going to have to do

If you set the newline to "os" you aren't actually changing things from the default - formatting the file via WSL will change the file endings to

\n

at which point a subsequent check will of course pass on linux and fail on windows. If you change the

newline

setting to

\n

at this point, the check will pass on windows as that would be the line ending actually in use in the file after a cfformat run via WSL. Is there something in your simplified test scenario that I have wrong in the above?

Nope. you got it, that is all correct.