Panic with "hugo new"

[jmooring]

hugo v0.89.0-DEV-096F5E19+extended linux/amd64 BuildDate=2021-10-18T09:08:01-0700

Site configuration:

[languages.en]
weight = 1
contentDir = 'content/en'
[languages.de]
weight = 2
contentDir = 'content/de' 

Then I tried to create a new page:

hugo new content/en/post/foo.md

panic: runtime error: index out of range [-1]

goroutine 1 [running]:
github.com/gohugoio/hugo/hugolib/filesystems.(*BaseFs).AbsProjectContentDir(0x7ffffbf0a00b, {0x7ffffbf0a00b, 0x11})
        /home/jmooring/code/hugo/hugolib/filesystems/basefs.go:158 +0x165
github.com/gohugoio/hugo/hugolib.ContentFactory.SectionFromFilename({0xc00062ef20, 0xc000966200, 0xc000966240}, {0x7ffffbf0a00b, 0x25422c0})
        /home/jmooring/code/hugo/hugolib/content_factory.go:98 +0x65
github.com/gohugoio/hugo/create.NewContent(0xc00062ef20, {0x0, 0x0}, {0x7ffffbf0a00b, 0x684985})
        /home/jmooring/code/hugo/create/content.go:65 +0x439
github.com/gohugoio/hugo/commands.(*newCmd).newContent(0xc00053d050, 0xc0007da000, {0xc000405b50, 0x1, 0x0})
        /home/jmooring/code/hugo/commands/new.go:83 +0x150
github.com/spf13/cobra.(*Command).execute(0xc0007da000, {0xc000405b20, 0x1, 0x1})
        /home/jmooring/go/pkg/mod/github.com/spf13/cobra@v1.2.1/command.go:856 +0x60e
github.com/spf13/cobra.(*Command).ExecuteC(0xc0003e4f00)
        /home/jmooring/go/pkg/mod/github.com/spf13/cobra@v1.2.1/command.go:974 +0x3bc
github.com/gohugoio/hugo/commands.Execute({0xc00003c0a0, 0x2, 0x2})
        /home/jmooring/code/hugo/commands/hugo.go:92 +0xb4
main.main()
        /home/jmooring/code/hugo/main.go:23 +0x58

This also produced an orphaned ".hugo_build.lock" file in the root of the project.

[jmooring]

The content/ directory was empty when I tried to create the new page. It did not contain en/ or de/ subdirectories.

[bep]

This also produced an orphaned ".hugo_build.lock" file in the root of the project.

There's no such thing as an orphaned ".hugo_build.lock".

[bep]

I suspect is a symptom of "something else" (which we need to fix), but could you try to do the same with:

[[module.mounts]]
  source = 'content/en'
  target = 'content'
  lang = 'en'
[[module.mounts]]
  source = 'content/de'
  target = 'content'
  lang = 'de'

[jmooring]

Starting each test with an empty content/ directory...

This fails:

[languages.en]
  weight = 1
  contentDir = 'content/en'
[languages.de]
  weight = 2
  contentDir = 'content/de'

[[module.mounts]]
  source = 'content/en'
  target = 'content'
  lang = 'en'
[[module.mounts]]
  source = 'content/de'
  target = 'content'
  lang = 'de'

This works:

[languages.en]
  weight = 1
  # contentDir = 'content/en'
[languages.de]
  weight = 2
  # contentDir = 'content/de'

[[module.mounts]]
  source = 'content/en'
  target = 'content'
  lang = 'en'
[[module.mounts]]
  source = 'content/de'
  target = 'content'
  lang = 'de'

[bep]

I will fix this tomorrow, thanks for testing ...

[jmooring]

There's no such thing as an orphaned ".hugo_build.lock".

This may generate some noise in the forum...

• "Why is this file in my directory?"
• "Is it OK to delete it?"
• "It says it is a build file, but I haven't built my site."
• "Should I check this into source control, or should I add it to my .gitignore?"

[bep]

This may generate some noise in the forum...

Sure, but it's there for a good reason. I'm going to document it.

• It's effectively a "file mutex", preventing data races between multiple Hugo builds.
• It would not make sense for us to somehow delete it when done, because ... that's not how it works.
• It uses OS File locking, so that file could also be used by external programs/scripts, e.g. when they want to copy large amount of content into /content with a running server.
• I would recommend just put it in .gitignore and forget about it.

[bep]

@jmooring I can reproduce the above, but only if the source contentDIrectories do not exist, which sounds like a error situation to me ... Also, I get that same error situation in both of the above.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.