panic: runtime error: slice bounds out of range

[whitebook]

goroutine 1 [running]:
github.com/knq/dburl.mssqlProcess(0xc8200c4000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/apps/go/src/github.com/knq/dburl/dburl.go:113 +0x886
github.com/knq/dburl.Parse(0x7ffc30de1e01, 0x35, 0xe0f1c0, 0x0, 0x0)
/apps/go/src/github.com/knq/dburl/dburl.go:79 +0x56a
main.openDB(0xc8201c2000, 0x0, 0x0)
/apps/go/src/github.com/knq/xo/xo.go:191 +0x63
main.main()
/apps/go/src/github.com/knq/xo/xo.go:43 +0x249

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1

I think this happens because my password needs to be escaped???

my password is "!234#$";

if I pass an invalid password it says it cant connect which the expected result, however when I try the actual one it has this message.

I have tried it on a another DB (postgres) without any fancy password and it worked great, so I am guessing it has to do with the password?

Thanks.

[Kenneth Shaw]

The issue here is the hash (#) character. This package just makes use of the standard net/url.Parse functionality, and when a hash character is in the password or the username portion of the host, it triggers the parsing of the hash as the 'fragment' of the URL. I've looked at ways of detecting / fixing this, but it's not really likely without writing a fully new URL parser. And quite frankly, what the underlying standard library is doing is probably the right thing anyways.

You can fix this with by changing the hash character to a %23 (the URL safe encoded value) and this should at least get it to work for your immediate use case. Additionally, I've been planning on adding to xo the ability to read passwords from the command line, so when that is available, you can simply input the password by hand. The only reason that feature doesn't exist now, is that xo is designed to be primarily used in some kind of automated build process, where it is expected that the user/pass to the database is not sensitive, and can easily be passed on the command line.

I will add some bounds checking, however, on the slice issue so that at least a better error message propagates up in this scenario.

[whitebook]

Sorry didnt see your response.
Thanks.