-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better Windows support & support for multiple fallback files #57
base: master
Are you sure you want to change the base?
Conversation
config_!linux.go
Outdated
@@ -0,0 +1,5 @@ | |||
//go:build !linux |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we use a different filename?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure thing; the "exclamation mark" seems stupid now that i am seeing it the second time. :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a look into this.
Looking at the GO reference : https://pkg.go.dev/cmd/go#hdr-Build_constraints
It seems that the xxx_!linux.go
notation for files goes hand in hand with the //go:build !linux
compile header.
There shouldn't be any difference between build contraints in file names and compile header.
It still is possible to rename the file with the drawback to handle all the different OSes in runtime.
And being unable to provide any os-spedific functions like SystemConfigFileFinder
(in case of linux)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated to filename to one without the special char; the //go:build !linux
compile header takes care of the build constraint.
example_test.go
Outdated
@@ -2,10 +2,9 @@ package ssh_config_test | |||
|
|||
import ( | |||
"fmt" | |||
"github.com/kevinburke/ssh_config" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This import should stay where it was
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the imports got sorted due to an automatic gofmt run after a file save,
I do not unterstand why github.com/kevinburke/ssh_config
needs to be at the and of the import block here.
Is it okay for you to explicitly put the import line at the end; like thiss ... :
import (
"fmt"
"path/filepath"
"strings"
)
import "github.com/kevinburke/ssh_config"
I'm really sorry but this is too large for me to review as of now. Is there a way to split this into several smaller PR's grouped by the type of functionality that is changing? |
There is an open question i could not get my head around.
As far as i undertood the test
TestIncludeSystem
it should by possible to imoprt a file/etc/ssh/kevinburke-ssh-config-test-file
by using the import commandimport kevinburke-ssh-config-*-file
in the file~/.ssh/config
. Imo it should not work this way. Is this a expected/wanted behaviour?