비슷: 구성,configuration
=설정파일,setting_file =,setting_file 설정파일 setting_file
{
보통 settings file 복수형으로 많이 쓰이고, configuration file configuration_file (구성파일, 구성,configuration 파일,file)이라는 이름이 더 많이 쓰이는데... 아무튼 pagename 이게 최선인 듯
=설정파일,setting_file =,setting_file 설정파일 setting_file
{
보통 settings file 복수형으로 많이 쓰이고, configuration file configuration_file (구성파일, 구성,configuration 파일,file)이라는 이름이 더 많이 쓰이는데... 아무튼 pagename 이게 최선인 듯
| 각 ...마다, | 이런 설정파일들이 있다 | ex. |
| user + shell 의 조합 | startup script | .bashrc, .profile, ...  .bashrc .profile |
| Gradle (Java의 build/test tool) | settings.gradle - see https://docs.gradle.org/current/userguide/settings_file_basics.html | |
| 옛날 Windows | .INI | see  INI_file .... Windows_Registry가 생긴 이유 중 하나가 이게 너무 지저분해서였나? 그래서 중심에 하나의 db로 통합하려는 시도...였나 - 기억이..chk |
| Java | .properties | see  .properties .properties .properties |
| 각종 program | 의 startup script | Emacs : .emacs / Vim : .vimrc / ... |
| build 예정인 source code | Makefile | 이것을 만들어주는 목적인 CMakeLists.txt Makefile.in ...등도 여럿 있다 / 한 술 더 떠 Makefile.in을 만드는 Makefile.am 도 있다 |
옛날에는 PROPERTY=VALUE 의 나열 식의 text_file이 많이 보였고 (물론 간단하므로 지금도 자주 보인다)
XML도 많이 쓰였고 (유행이었다)
202x년대에는 .json .yaml 등이 많이 보인다. 그 사이에 쓰인 XML은 너무 verbose해서 주류에서는 도태된 듯. (쓰이긴 쓰인다)
i.e. lightweight_markup_languages 많이 보임.
executable한 shell script language로 된 것도 있고(이땐 매우 flexible + extensible + ...해지는 대신 보안문제 발생 가능),
그냥 property-value만 나열한게 물론 가장 흔하고. (rel. 키-값,key-value)
text인 게 대부분... 하지만 (obscure한) binary blob도 드물지는 않다.
그냥 property-value만 나열한게 물론 가장 흔하고. (rel. 키-값,key-value)
text인 게 대부분... 하지만 (obscure한) binary blob도 드물지는 않다.
암튼 대충 생각해본 분류기준은
- executable script file 인가 vs 아닌가
- 전자라면 무슨 PL을 쓰는가?
- 후자라면 format이 단순한 key=value 나열인가, 아님 markup_language 같은 걸 쓰나
- 전자라면 '약하게' type을 지정해주는 어떤 convention이 있다, string value의 경우 ""로 둘러싸는 등. 유니버설한 표준은 물론 없고.
- 후자라면 markup_language 는 그 많은 *ML 중에 뭘 쓰는가?
- 전자라면 '약하게' type을 지정해주는 어떤 convention이 있다, string value의 경우 ""로 둘러싸는 등. 유니버설한 표준은 물론 없고.
- 전자라면 무슨 PL을 쓰는가?
}