Skip to content
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

coco -c loses .js suffix when filename contains more than one . #234

Open
ksdlck opened this issue Nov 4, 2013 · 2 comments
Open

coco -c loses .js suffix when filename contains more than one . #234

ksdlck opened this issue Nov 4, 2013 · 2 comments

Comments

@ksdlck
Copy link

ksdlck commented Nov 4, 2013

coco -c seems to be dropping the expected .js suffix when invoked on a file that contains more than one . in its name. Consider the following:

$ ls
test.co                         test.filename.with.more.dots.co
test.filename.co
$ coco -c test.co
$ coco -c test.filename.co
$ coco -c test.filename.with.more.dots.co
$ ls
test.co                         test.filename.with.more.dots
test.filename                   test.filename.with.more.dots.co
test.filename.co                test.js

The contents of all compiled files are correct, but two of three lack the expected .js suffix.

@vendethiel
Copy link
Contributor

#155

@ksdlck
Copy link
Author

ksdlck commented Nov 4, 2013

I must admit, I'm not particularly convinced by this argument. Coco has always adopted a strongly "It's just Javscript" mentality, and this somehow feels contradictory to that, if only peripherally. Is it possible that the real problem is that coco has never had an option for outputting to a file, as opposed to -o which outputs to a predetermined filename in the specified directory? Naturally, the same can be accomplished by -p and redirection to your filename of choice, e.g. (as a counter to #155):

$ coco -cp test.jsm.co > test.jsm

It strikes me that the default behavior should be consistent regardless of the number of suffixes the filename has. I'm ok with applying the solution above in reverse to deal with the current behavior, but why is this the default? Are there lots of folks out there finding this behavior helpful?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants