gitbook 입문 강좌의 해결 윈도우즈 핫로드 실패 문제
20663 단어 gitbook
파경은 어떻게 노란색을 붙이는가
gitbook
Windows
시스템은 핫 로딩할 수 없습니다. 항상 오류를 보고합니다!gitbook
는 문서 작성기로 편리하게 markdown
아름답고 우아하게 출력할 수 있다html
, gitbook serve
서버를 시작하면 원래 평범한 외모의 markdown
미운 오리가 몸을 흔들면 경국지색html
절색가인이 된다.원본 파일이 변경되면
Windows
예상대로 서버를 다시 시작할 수 없으며, 직접 이상을 던져 markdown
화장을 즉시 종료합니다.Restart after change in file README.md
Stopping server
events.js:183
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'F:\workspace\private-cloud-backup\gitbook-test\_book'
대경 스티커 옐로우
이제
markdown
신데렐라가 html
언니로 변신하는 신기한 과정을 살펴봅시다!$ gitbook serve --log=debug
Live reload server started on port: 35729
Press CTRL+C to quit ...
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\gitbook-test\_book"
info: 7 plugins are installed
info: loading plugin "livereload"... OK
...
info: loading plugin "theme-default"... OK
info: found 1 pages
info: found 0 asset files
debug: calling hook "config"
debug: calling hook "init"
debug: copy assets from theme C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-theme-default\_assets\website
...
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-livereload\book
debug: generate page "README.md"
debug: calling hook "page:before"
debug: calling hook "page"
debug: index page README.md
debug: calling hook "finish:before"
debug: calling hook "finish"
debug: write search index
info: >> generation finished with success in 1.5s !
Starting server ...
Serving book on http://localhost:4000
상기 출력 로그에 근거하여 우리는
gitbook
의 기본 운행 절차를 분석할 수 있다.readme
파일이 로드되고 있는 경우 summary
파일도 로드되며 glossary
디렉토리debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\gitbook-test\_book"
_book
플러그인을 설치하십시오.info: 7 plugins are installed
info: loading plugin "livereload"... OK
info: loading plugin "highlight"... OK
info: loading plugin "search"... OK
info: loading plugin "lunr"... OK
info: loading plugin "sharing"... OK
info: loading plugin "fontsettings"... OK
info: loading plugin "theme-default"... OK
info: found 1 pages
info: found 0 asset files
debug: calling hook "config"
debug: calling hook "init"
debug: copy assets from theme C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-theme-default\_assets\website
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-fontsettings\assets
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-sharing\assets
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-lunr\assets
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-search\assets
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-highlight\css
debug: copy resources from plugin C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\gitbook-plugin-livereload\book
gitbook install
,page:before
리셋 함수를 실행합니다. 모든 페이지가 실행된 후에 page
와finish:before
리셋 함수를 실행합니다.debug: generate page "README.md"
debug: calling hook "page:before"
debug: calling hook "page"
debug: index page README.md
debug: calling hook "finish:before"
debug: calling hook "finish"
debug: write search index
Starting server ...
Serving book on http://localhost:4000
기본적으로 서버가 시작되면 두 개의 포트를 차지하는데, 하나는 외부에 노출된
finish
포트로 브라우저 액세스 항목에 사용됩니다.또 하나는
4000
포트로 로컬 파일의 변화를 감청하고 서버를 재부팅하여 열 로딩 기능을 실현한다.로컬 서버가 시작된 후에 우리는
35729
정적 사이트 효과를 미리 볼 수 있고, http://localhost:4000
원본 파일은 markdown
풍부한 텍스트 파일로 화려하게 변할 수 있다.파경 화장
불행하게도
html
핫 로딩에 문제가 있을 수 있습니다. 즉, 서버를 시작한 후 로컬 파일이 바뀌면 핫 로딩 기능을 촉발하여 오류가 발생합니다Windows
. 그러면 브라우저가 접근할 수 없습니다.방금 변신한
Error: EPERM: operation not permitted
순간적으로 다시 원형으로 되돌아와 화장 후의 얼굴을 감상할 수 없게 되었습니다. 이런 체험은 상당히 좋지 않습니다!화장을 하면서 거울을 보는 것이야말로 마음속에 꿍꿍이가 있고 수시로 조정하는 것이다. 거울을 보지 않고 직접 화장을 하는 것은 보통 사람이 할 수 있는 것이 아니다.
markdown
로컬 서버를 가동하여 우리에게 거울을 제공했지만 열부하에 실패하여 거울을 깨뜨렸는데 어떻게 즐겁게 화장을 합니까?Restart after change in file README.md
Stopping server
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\gitbook-test\_book"
events.js:174
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'G:\sublime\gitbook-test\_book'
Emitted 'error' event at:
at FSWatcher._handleError (C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\chokidar\index.js:236:10)
at ReaddirpReadable.emit (events.js:189:13)
at Immediate. (C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\chokidar
ode_modules\readdirp\stream-api.js:82:32)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
의사를 찾아 문진하고 파경을 수리하다.
이제 문제가 재현되었으니 다음은 파경을 다시 일으켜 신데렐라를 사랑하는
gitbook
언니로 만들기 위해 의사를 찾아 진찰을 시작해야 한다.오류 정보 설명에 따라 삭제
markdown
디렉터리를 찾아 다시 이 디렉터리를 만들 때 알림html
은 조작할 권리가 없습니다.코난 부체
조작 권한의 문제라면
_book
디렉터리가 현재 어떤 상태인지 봅시다!$ ls
gitbook-errorforwindows-preview.png README.md SUMMARY.md
현재 프로젝트에
EPERM: operation not permitted
디렉터리가 없습니다. 오류가 발생했을 때 _book
디렉터리가 삭제되었음을 증명하지만, 어떤 이유로 이 폴더를 다시 만들 권리가 없어서 다시 시작하는 데 실패했습니다.그러나 이것은 현상일 뿐이다. 선생님은 현상을 통해 본질을 보아야 한다고 말씀하셨다. 현재
_book
파일이 없어도 서버를 다시 시작하면 성공해서 _book
파일을 만들 수 있기 때문에 하나만 있고 싶다!바로
_book
컨트롤러가 거짓말을 하고 있다!_book
디렉터리를 만들 권리가 없다는 혐의를 배제했지만 서버를 재부팅했지만 gitbook
디렉터리를 만들지 못했다는 것은 어떻게 설명할 수 있을까?debug: cleanup folder "G:\sublime\gitbook-test\_book"
events.js:174
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'G:\sublime\gitbook-test\_book'
Emitted 'error' event at:
at FSWatcher._handleError (C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\chokidar\index.js:236:10)
at ReaddirpReadable.emit (events.js:189:13)
at Immediate. (C:\Users\snowdreams1006\.gitbook\versions\3.2.3
ode_modules\chokidar
ode_modules\readdirp\stream-api.js:82:32)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
먼저
gitbook
이상 정보를 보십시오. _book
.분석 결과:
_book
는 사유 방법으로 이상 정보를 처리하는 역할을 하는데 이 사고와 관련이 크지 않다.Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ sed -n "223,239p" ~/.gitbook/versions/3.2.3/node_modules/chokidar/index.js
// Private method: Common handler for errors
//
// * error - object, Error instance
//
// Returns the error if defined, otherwise the value of the
// FSWatcher instance's `closed` flag
FSWatcher.prototype._handleError = function(error) {
var code = error && error.code;
var ipe = this.options.ignorePermissionErrors;
if (error &&
code !== 'ENOENT' &&
code !== 'ENOTDIR' &&
(!ipe || (code !== 'EPERM' && code !== 'EACCES'))
) this.emit('error', error);
return error || this.closed;
};
우리는 이어서 아래를 찾아 다시 한 번 보았다
FSWatcher._handleError
. 여기는 파일의 구체적인 경로를 제시하지 않았기 때문에 당분간 위치를 정할 수 없습니다.그럼 다음
sed -n "223,239p" ~/.gitbook/versions/3.2.3/node_modules/chokidar/index.js
: FSWatcher._handleError
Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ sed -n "78,96p" ~/.gitbook/versions/3.2.3/node_modules/chokidar/node_modules/readdirp/stream-api.js
proto._handleFatalError = function (err) {
var self = this;
setImmediate(function () {
if (self._paused) return self._errors.push(err);
if (!self._destroyed) self.emit('error', err);
});
}
function createStreamAPI () {
var stream = new ReaddirpReadable();
return {
stream : stream
, processEntry : stream._processEntry.bind(stream)
, done : stream._done.bind(stream)
, handleError : stream._handleError.bind(stream)
, handleFatalError : stream._handleFatalError.bind(stream)
};
}
유감스럽게도 여전히 구체적인 문제를 찾지 못했으니, 계속해서 단서 하나를 봅시다.
ReaddirpReadable.emit (events.js:189:13)
와Immediate.
모두 구체적인 파일 위치를 표시하지 않았으니 sed -n "78,96p" ~/.gitbook/versions/3.2.3/node_modules/chokidar/node_modules/readdirp/stream-api.js
모듈에 있었으면 좋겠다.Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ tree -P "events.js" --prune ~/.gitbook/versions/3.2.3/
/c/Users/Administrator/.gitbook/versions/3.2.3/
└── node_modules
├── cheerio
│ └── node_modules
│ └── jsdom
│ └── lib
│ └── jsdom
│ └── level2
│ └── events.js
└── gitbook-plugin-theme-default
└── src
└── js
└── core
└── events.js
11 directories, 2 files
Administrator@snowdreams1006 MINGW64 /f/workspace/private-cloud-backup/gitbook-test (master)
$ tree -P "timers.js" --prune ~/.gitbook/versions/3.2.3/
/c/Users/Administrator/.gitbook/versions/3.2.3/
0 directories, 0 files
timers.js:705:18
명령줄이 정상적으로 없음events.js:189:13
명령, 확장이 필요하면 다른 문장을 참고하십시오.육안 검증을 통해
chokidar
행 파일이 아예 없기 때문에 이 두 파일은 대부분 목표 파일이 아니다.명령줄에서 대상 파일을 찾을 수 없으니 전문적인 검색 도구인 전체 시스템에서 이 두 파일을 찾으십시오. 여기에는
git-bash
검색 도구가 사용됩니다.그러나 병란은 여전히 목표 파일을 찾지 못했다.
코난이 아니어서 진실을 발견하지 못했다
정부에 도움을 청하다.
tree
그런데 개원 제품인데 문제가 생긴 건 나만 있는 게 아닐 거예요. 그래서 events.js
에 가서 저와 같은 문제가 생겼는지 확인해 보세요.뜻이 맞는 동료를 찾았지만 해결책을 제공하지 않고 정부도 포기했으니 내가 미련이 있겠는가?
클릭하여 gitbook serve livereload 오류 보기
스스로 하다
가장 두려운 것은
174
가 아니라 Everything
를 발견했지만 위치를 정할 수 없었다. 컨트롤러에 잘못된 정보가 있었지만 진정한 파일을 찾지 못했다!먼저 현재 시스템 버전을 확인한 다음 버전 전환 방식으로 다른 버전에 이 문제가 있는지 테스트합니다.
$ gitbook --version
CLI version: 2.3.2
GitBook version: 3.2.3
gitbook
은 현재 설치된 버전을 표시하고 github
은 원격 서버 버전을 표시합니다.#
$ gitbook ls
GitBook Versions Installed:
* 3.2.3
Run "gitbook update" to update to the latest version.
#
$ gitbook ls-remote
Available GitBook Versions:
4.0.0-alpha.6, 4.0.0-alpha.5, 4.0.0-alpha.4, 4.0.0-alpha.3, 4.0.0-alpha.2, 4.0.0-alpha.1, 3.2.3, 3.2.2, 3.2.1, 3.2.0, 3.2.0-pre.1, 3.2.0-pre.0, 3.1.1, 3.1.0, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 3.0.0-pre.15, 3.0.0-pre.14, 3.0.0-pre.13, 3.0.0-pre.12, 3.0.0-pre.11, 3.0.0-pre.10, 3.0.0-pre.9, 3.0.0-pre.8, 3.0.0-pre.7, 3.0.0-pre.6, 3.0.0-pre.5, 3.0.0-pre.4, 3.0.0-pre.3, 3.0.0-pre.2, 3.0.0-pre.1, 2.6.9, 2.6.8, 2.6.7, 2.6.6, 2.6.5, 2.6.4, 2.6.3, 2.6.2, 2.6.1, 2.6.0, 2.5.2, 2.5.1, 2.5.0, 2.5.0-beta.7, 2.5.0-beta.6, 2.5.0-beta.5, 2.5.0-beta.4, 2.5.0-beta.3, 2.5.0-beta.2, 2.5.0-beta.1, 2.4.3, 2.4.2, 2.4.1, 2.4.0, 2.3.3, 2.3.2, 2.3.1, 2.3.0, 2.2.0, 2.1.0, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 2.0.0-beta.5, 2.0.0-beta.4, 2.0.0-beta.3, 2.0.0-beta.2, 2.0.0-beta.1, 2.0.0-alpha.9, 2.0.0-alpha.8, 2.0.0-alpha.7, 2.0.0-alpha.6, 2.0.0-alpha.5, 2.0.0-alpha.4, 2.0.0-alpha.3, 2.0.0-alpha.2, 2.0.0-alpha.1
Tags:
latest : 2.6.9
pre : 4.0.0-alpha.6
현재 최신 발표 버전은
bug
이며, 우리 로컬에 설치된 버전은 바로 이 버전이기 때문에 현재 bug
버전을 테스트해야 합니다.gitbook ls
를 보면 가슴이 두근거린다. 버전 관리 약정에 따라 버전 번호는 일반적으로 세 부분으로 구성되어 있다. 첫 번째 부분은 호환되지 않는 중대한 업그레이드를 대표하고 두 번째 부분은 주요 부분과 호환되는 기능의 업그레이드를 대표하며 세 번째 부분은 작은 버전의 복구를 대표한다.gitbook ls-remote
에서 3.2.3
로 직접 넘어가는 것은 4.0.0-alpha.6
에 중대한 재구성이 발생했다는 것을 의미합니다!됐어, 일단 다운로드해 봐!
4.0.0-alpha.6
다운로드 및3.2.3
업그레이드, 두 가지 방식 모두 최신 버전을 체험할 수 있습니다. 여기에서 다운로드 방식을 선택하면 서로 다른 버전의 전환을 편리하게 할 수 있습니다.# `4.0.0-alpha.6`
$ gitbook fetch 4.0.0-alpha.6
Installing GitBook 4.0.0-alpha.6
[email protected] C:\Users\SNOWDR~1\AppData\Local\Temp\tmp-8912hSrxNvTCrFEH
ode_modules\gitbook
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
GitBook 4.0.0-alpha.6 has been installed
우선 로컬 설치
4.0.0-alpha.6
버전을 보고 이따가 실행될 때 최신 버전gitbook
을 사용하도록 하세요.#
$ gitbook ls
GitBook Versions Installed:
* 4.0.0-alpha.6
3.2.3
Run "gitbook update" to update to the latest version.
#
$ gitbook current
GitBook version is 3.2.3
gitbook fetch
버전을 실행하고 gitbook update
레벨 로그를 인쇄합니다.의외로 시작도 하지 못했습니다.
gitbook
파일을 열 수 없음을 알립니다.버전 번호 규범을 돌이켜보면
4.0.0-alpha.6
부터 gitbook serve --gitbook=4.0.0-alpha.6 --log=debug
까지 변경이 비교적 크고 버전이 호환되지 않을 수도 있습니다. 프로젝트를 다시 초기화해보세요!# `gitbook`
$ gitbook init --gitbook=4.0.0-alpha.6
Warning: Accessing PropTypes via the main React package is deprecated, and will be removed in React v16.0. Use the latest available v15.* prop-types package from npm instead. For info on usage, compatibility, migration and more, see https://fb.me/prop-types-docs
info: create SUMMARY.md
info: initialization is finished
그러나, 여전히 같은 오류를 보고하고, 여전히 시작할 수 없습니다.
$ gitbook serve --gitbook=4.0.0-alpha.6 --log=debug Warning: Accessing PropTypes via the main React package is deprecated, and will be removed in React v16.0. Use the latest available v15.* prop-types package from npm instead. For info on usage, compatibility, migration and more, see https://fb.me/prop-types-docs
Live reload server started on port: 35729
Press CTRL+C to quit ...
...
Error: ENOENT: no such file or directory, open 'C:\Users\snowdreams1006\.gitbook\versions\4.0.0-alpha.6
ode_modules\gitbook-plugin-livereload\_assets\plugin.js'
이 길은 통하지 않으니 다시 한 번 바꿔라. 위로는 처리할 수 없으니 아래로 물러나면 결과가 있지 않겠는가?
4.0.0-alpha.6
, 최신 테스트 버전은 debug
이지만 최근에 제출한 버전은 ~\.gitbook\versions\4.0.0-alpha.6
ode_modules\gitbook-plugin-livereload\_assets\plugin.js
입니까?왜
v3
관리된 v4
버전 번호가 갑자기 다이빙을 하는데 어떤 고양이 냄새가 나지 않을까요?$ gitbook ls-remote
Available GitBook Versions:
4.0.0-alpha.6, 4.0.0-alpha.5, 4.0.0-alpha.4, 4.0.0-alpha.3, 4.0.0-alpha.2, 4.0.0-alpha.1, 3.2.3, 3.2.2, 3.2.1, 3.2.0, 3.2.0-pre.1, 3.2.0-pre.0, 3.1.1, 3.1.0, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 3.0.0-pre.15, 3.0.0-pre.14, 3.0.0-pre.13, 3.0.0-pre.12, 3.0.0-pre.11, 3.0.0-pre.10, 3.0.0-pre.9, 3.0.0-pre.8, 3.0.0-pre.7, 3.0.0-pre.6, 3.0.0-pre.5, 3.0.0-pre.4, 3.0.0-pre.3, 3.0.0-pre.2, 3.0.0-pre.1, 2.6.9, 2.6.8, 2.6.7, 2.6.6, 2.6.5, 2.6.4, 2.6.3, 2.6.2, 2.6.1, 2.6.0, 2.5.2, 2.5.1, 2.5.0, 2.5.0-beta.7, 2.5.0-beta.6, 2.5.0-beta.5, 2.5.0-beta.4, 2.5.0-beta.3, 2.5.0-beta.2, 2.5.0-beta.1, 2.4.3, 2.4.2, 2.4.1, 2.4.0, 2.3.3, 2.3.2, 2.3.1, 2.3.0, 2.2.0, 2.1.0, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 2.0.0-beta.5, 2.0.0-beta.4, 2.0.0-beta.3, 2.0.0-beta.2, 2.0.0-beta.1, 2.0.0-alpha.9, 2.0.0-alpha.8, 2.0.0-alpha.7, 2.0.0-alpha.6, 2.0.0-alpha.5, 2.0.0-alpha.4, 2.0.0-alpha.3, 2.0.0-alpha.2, 2.0.0-alpha.1
Tags:
latest : 2.6.9
pre : 4.0.0-alpha.6
이런 의문을 가지고
3.2.3
버전을 다운로드해 보세요. 핫로드가 가능한지 확인해 보세요.4.0.0-alpha.6
지정2.6.9
버전, 여전히 실패!$ gitbook serve --log=debug --gitbook=2.6.9
Error loading version latest: Error: Cannot find module 'q'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:582:15)
at Function.Module._load (internal/modules/cjs/loader.js:508:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18)
at Object. (C:\Users\myHome\.gitbook\versions\2.6.9\lib\index.js:3:9)
at Module._compile (internal/modules/cjs/loader.js:701:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
at Module.load (internal/modules/cjs/loader.js:600:32)
at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
at Function.Module._load (internal/modules/cjs/loader.js:531:3)
TypeError: Cannot read property 'commands' of null
다시 현장으로 돌아가다
이제 최초의 사건 현장에 다시 시선을 집중시키면 이번에는 배수진을 치고 싸울 수밖에 없다. 스스로 손을 쓰든지, 밥을 먹든지, 굶어 죽든지, 얼어 죽든지!
Stopping server
debug: readme found at README.md
debug: summary file found at SUMMARY.md
debug: cleanup folder "G:\sublime\private-cloud-backup\gitbook-test\_book"
events.js:174
throw er; // Unhandled 'error' event
^
Error: EPERM: operation not permitted, lstat 'G:\sublime\private-cloud-backup\gitbook-test\_book'
Emitted 'error' event at:
at FSWatcher._handleError (C:\Users\myHome\.gitbook\versions\3.2.3
ode_modules\chokidar\index.js:236:10)
at ReaddirpReadable.emit (events.js:189:13)
at Immediate. (C:\Users\myHome\.gitbook\versions\3.2.3
ode_modules\chokidar
ode_modules\readdirp\stream-api.js:82:32)
at runCallback (timers.js:705:18)
at tryOnImmediate (timers.js:676:5)
at processImmediate (timers.js:658:5)
상술한 오류 설명에서 진실은 단지 한 장에서 검토한 바와 같다. 당시 결론은
gitbook-ci
폴더를 삭제하고 gitbook
폴더를 새로 만들 때 의외의 일이 일어났다는 것이다.만약 이 행위가
bug
에서 발생한 것이 아니라 우리가 수동으로 관여한 것이라면, 즉, 로컬 서버를 성공적으로 시작한 후 핫로드가 발생하기 전에 인위적으로 2.6.9
폴더를 삭제하면 어떤 일이 일어날까요?내 추측은:
gitbook serve --log=debug --gitbook=2.6.9
의 열 로딩 메커니즘은 로컬 파일 디렉터리 시스템의 변화를 감청하고 서버를 멈추고 다시 시작하는 것이기 때문이다.gitbook
폴더를 수동으로 삭제했습니다. gitbook
다시 서버를 리셋하는 순간에 갑자기 _book
폴더가 없는 것을 발견했습니다. 이때 삭제하지도 않고 새로 만들지도 않을 때 이상이 발생했습니다. 직접 새로 만들기_book
폴더를 만드는 것과 같습니다. 열부하를 초기 시작 모드로 바꾸는 것입니다!하늘이 나를 저버리지 않기를 바란다. 만약 안 된다면 원본 논리를 보고 찾을 수밖에 없다
gitbook
.어떻게 될까요?
_book
! gitbook
로컬 서버를 시작한 후 로컬 파일이 수정되면 리셋에 실패합니다!_book
디렉터리를 삭제하면 로컬 파일이 수정될 때 서비스를 재개하는 데 성공할 수 있습니다.여기까지 드디어 해결 방안을 찾았습니다. 바로 서비스를 시작한 후
gitbook
디렉터리를 삭제하는 것입니다.완벽한 총결은 아니에요.
_book
시스템에서 _book
서비스를 시작한 후 로컬 파일이 변경되면 핫 플러스가 실패합니다.서버를 시작한 후
bug
디렉터리를 삭제하면 나중에 로컬 파일을 어떻게 수정해도 순조롭게 다시 시작할 수 있습니다.아직 문제의 근원을 찾지 못했기 때문에 다음에 원본 코드를 깊이 파고들어 도대체 어디에 문제가 생겨서
it works
시스템을 다시 시작할 수 없는지 계속 연구할 것이다.제때에
gitbook serve --log=debug
목록을 삭제하는 것은 좋은 해결 방안은 아니지만 적어도 _book
신데렐라는 _book
언니로 분장할 수 있다!
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
직무 경력서를 GitLab Pages를 사용하여 공개해 보았습니다.장기간의 휴가가 되어, 정리된 시간을 잡을 수 있었기 때문에 자신의 2년간의 되돌아보고, 막상이라는 때를 위해서 직무 경력서 되는 것을 써 보려고 했다. 형식을 살펴보면 PDF나 Word와 같은 형식이 주류인 것 같...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.