codeheart 위치로그  |  태그  |  미디어로그  |  방명록
icon [powershell] 파워쉘 속성 튜토리얼
개발/Script | 2013. 9. 14. 20:44

powershell 3.0 으로 테스트하였습니다.


PowerShell 은 좀 더 발전된 쉘 스크립팅을 지원한다.

텍스트 기반이 아닌 오브젝트 기반이며, 이로써 더 강력한 기능을 쉽게 가능하게 해준다.

이 점이 장점이 될지는 지켜봐야 하겠지만, 비-리눅스 개발자라면 메리트가 충분히 있어 보인다.


이와 같은 shell script 말고 ruby, python 을 shell script 처럼 사용하는 경우도 많지만,

shell script 가 파일경로 및 디렉토리 구조에 대해 쉽게 사용될 수 있도록 특화되어 있기 때문에

익숙하기만 하면 더 짧은 코드로 작성이 가능하다.


powershell 은 윈도우 쉘 답게 명령어에 대소문자를 가리지 않는다.

파라메터 규칙은 보통 -option 과 같은 방식을 따른다.

cmd shell 에서 보통 /option 과 같이 하는 것과 대조된다.

(아마도 윈도우 개발자들도 요즘은 linux 스타일 path 구분자 / 을 사용하는 경우가 많아서 그런게 아닐까 싶다)

이는 unix 계열의 구형 옵션 방식과 유사하다. (요즘은 거의 GNU style 로 통일되는 듯 싶지만)



[[출력해보기]]

echo 'hello'


write-host 'hello'


$your_name = 'name'

write-host "hello ${your_name}"


write-host "hello" ${your_name}

사실 echo 와 write-host 는 엄밀히 다르다.

write-host 가 cmd 의 echo 와 같으며, echo 는 복잡한 개체를 표시할 때 title column 이 표시되는 특징이 있다.



[[현재 폴더 모든 파일명앞에 'value = ' 을 붙여 출력하는 방법 #1]]

foreach($item in gci) { write-host 'value =' $item}


foreach($item in gci | select name) { write-host 'value =' $item.name}

foreach($item in gci | select *) { write-host 'value =' $item.name}


gci 는 Get-ChildItem 의 약자이자 alias 명령어로

dir 및 ls 과 유사하지만, 결과물을 item 목록으로 준다고 보면 된다.(오브젝트 기반 스크립트이므로)

select 는 그 목록 개별 레코드 중 특정 컬럼(오브젝트)만 취하는 것이다.

( bash 으로 하려면 복잡해진다. grep/awk 등 텍스트 파싱을 위한 여러 조합이 나올 것이다 )


object 기반이기 때문에 gci 의 결과물은 객체라 봐도 무방하다.

그래서 $item.name 같이 특정 컬럼(오브젝트)에 멤버 변수처럼 접근하는 것도 가능하다.



[[현재 폴더 모든 파일명앞에 'value = ' 을 붙여 출력하는 방법 #2]]

gci | ForEach-Object{write-host 'value =' $_}

gci | foreach{write-host 'value =' $_}

gci | %{write-host 'value =' $_}

이는 다소 독특한 방법인데, gci 의 출력(파일 리스트)의 요소 각각에 대해서 무언가 다른 작업을 해주는 것이다. ruby 의 .each{ 와 비슷한데 $_ 는 그 해당 요소 하나를 의미한다. 위에서는 $item 이라 보면 된다. % 는 축약형으로 사실은 ForEach-Object 이다. foreach 로도 사용할 수 있다.
(하지만, foreach(...) {} 과 같은 문법을 ForEach-Object 로는 대체할 수 없다!)

이 방법이 foreach(...) {...} 방식보다 쉘스크립트에 더 적합한 것 같다.


[[현재 폴더 모든 파일명 중에 'vim' 이라는 글자가 들어간 경우만 출력하는 방법]]

foreach($item in gci) { if($item.name -like '*vim*') { write-host $item} }


foreach($item in gci) { if($item.name.contains('vim')) { write-host $item} }


gci | %{if($_.name -like '*vim*') { write-host $_ }}



[[오브젝트 멤버 보기]]

python 의 dir. ruby 의 .methods 같은 기능이다.

powershell 은 객체지향이므로 이런 것을 알아두면 공부할 때 도움이 된다.


"text" | get-member // "text" 객체의 member 보기


[string] | get-member // string 타입의 member 보기



/* method 목록만 보기 */


// 맨위에 Name ===== 과 같은 헤더 컬럼명이 생략되는 방법

[string].GetMethods() | select name


// 맨위에 Name ===== 과 같은 헤더 컬럼명이 생략되는 방법(들)

[string].GetMethods() | %{$_.name}


[string].GetMethods() | %{write-host $_.name}


[string].GetMethods() | ft -hide


ft -hide 는 Format-Table -hidetableheaders 의 줄임 명령이다.



arrow 트랙백 | 댓글



icon Windows 8.1, 8, 7, Vista, Xp...
컴퓨터 | 2013. 9. 14. 17:31

먼저, 주관적인 견해임을 말씀드립니다.



윈도우7는 사용자 관점에서 훌륭한 OS 입니다.


그렇다면, 사용자 층이 적은 Windows 8 은 별로인가?


아직도 점유율이 높은 Windows XP 는 역대 최고의 MS 운영체제인가?


여러 관점에서 볼 일이긴 합니다.


[자사 OS 끼리 비교하자면]


내가 볼 때 윈도우는 일반 사용자용 윈도우도 NT 커널로 넘어간 후로 충분히 훌륭하다고 봅니다.


윈도우7 은 그 간 OS 들이 욕을 먹었던 것과 달리 상당히 호평을 받았음에도 불구하고 처음 점유율은 좋지 않았습니다. 최고의 OS(?) Windows XP 가 팀킬을 하고 있었기 때문입니다.

하지만 Windows XP 도 처음엔 욕을 먹었던 것을 기억해야 합니다.

Windows 95, 98 에 비해 너무 무겁다... 하지만 시대가 지난 지금은 너무 가벼워서 탈입니다.

게다가 Windows 95, 98 같은 비-NT(DOS) 기반 OS 의 경우에는 안정성 까지 최악이었죠.

윈도우Vista 역시 비운의 OS 입니다.

분명 UI 측면에서 현대 윈도우 버젼의 근간이 되는 많은 변화를 주었지만, 확실히 성능상 문제가 있었습니다. UI 를 거의 이어받고 성능을 획기적으로 개선한 Windows 7 이 호평을 받은 것은 당연합니다.


하지만, Windows 8 은 홀짝 순서에 따라 과연 망작일까? 시작 버튼, 시작 메뉴를 없앤 것은 과연 잘한 선택일까? 이 부분은 잘 모르겠습니다. 결과론 적인것이라, 너무 MS가 앞서 나가서 사용자가 적응하지 못할 것일수도 있고, 완전한 오판일 수도 있습니다.

그 부분만을 제외하고 본다면 Windows 8 은 상당히 좋습니다. 안정적일 뿐더러, Windows 7 보다도 더 빠르고, 메모리도 더 적습니다. 태블릿용으로 나온 OS 라 작정하고 만든 느낌은 듭니다.

확실히 데스크탑 사용자로서는 큰 메리트가 없는 것은 사실입니다.

제 생각은 윈도우7 에 만족한다면 굳이 바꿀 필요는 없지만, 그렇다고 망작은 아니란 생각입니다.

확실히 쾌적함에 있어서는 윈도우 8 에서 더 만족을 했기 때문입니다.


윈도우8.1 프리뷰를 써본 결과, 윈도우8에서 지적되었던 시작버튼이 부활되었습니다.

그리고 시작화면으로 가지 않아도 컴퓨터를 부팅하거나 종료할 수 있습니다.

(여전히, 사용자 입장에서는 오른쪽 버튼을 마구 눌러서 탐구해봐야 하는 몇가지 단점이 보입니다)

사실 8.1 은 MS 가 8에서 사용자 입장을 반영하려고 만든 패치로 보이지만, 여전히 MS 의 똥고집이 보이기도 합니다. 시작 버튼은 살렸지만, 시작 메뉴를 살리지는 않았습니다.

결국 어떻게 버튼 버튼 모양만 생긴 꼴입니다. 그래서 8.1 역시 8 처럼 보급시키기에는 다소 무리가 있어 보입니다. 제 생각으로는 Windows 9 로 넘어가기 전에 사용자들의 사용자 경험의 반응을 다시 한번 확인해보려고 고집을 부리는 것 같습니다. 몇년을 더 두고 봐야겠네요.

그 것을 제외한다면, 윈도우8.1 은 (아직 프리뷰라 잔버그가 있지만) 윈도우8보다도 더 쾌적해졌습니다. 게다가 한 번 리뷰했던 익스플로러11 의 성능은 정말 만족스럽니다.

(다만, OS 자체를 놓고 보자면 익스플로러11 에 대해서는 생략하는 게 맞겟죠)


[비 MS OS 과 비교하자면...]


(주로 개발자겠지만) 혹자는 유닉스 계열(Linux, BSD 포함)과 비교하여 떨어지는 안정성 및 성능을 내세우며, 특히 OS 는 돈을 받고 팔면 안된다고까지 주장합니다.

공정성 문제가 항상 대두되기는 하지만... 그렇다고 리눅스 계열이 다 무료봉사하는 것은 아닙니다.

리눅스 계열도 돈을 받고 팔고 서포트 비용을 받기도 합니다. 역으로 생각해보면 윈도우 가격도 서포트 비용이라 간주하면 됩니다.


 - 역사를 본다면 UNIX 계열과 NT 계열을 그 근간이 다릅니다.

UNIX 계열은 더 오래되었으며, 당시 컴퓨터들은 지금과 같이 빠른 컴퓨터가 아니었습니다.

당연하게도 UNIX 는 GUI 보다는 CLI(Command Line Interface)를 강조하며,

이를 가지고 더 많은 일을 하는 쪽으로 발전되었습니다.

UNIX 의 쉘 역시 발전을 거듭했으며, 쉘을 통해 각종 실행파일을 연동해 더욱 강력한 일을

해낼 수 있습니다.


 - 하지만, NT 의 전신인 DOS 는 CLI 가 근간이긴 하지만 일반 사용자를 대상으로 하는 OS 이며,

일반 사용자는 당시 UNIX 해커들과 달리 그런 조합적인 쉘 스크립트를 작성하거나 사용할 여력이 되지 않습니다. 쉘 자체의 기능도 상대적으로 조악할 뿐더러 수행되는 CLI 어플리케이션의 기능들도

UNIX 처럼 여러 어플리케이션의 조합을 의도한 것이 아니라, 한 어플리케이션이 가능한 많은 일을 할 수 있도록 하는 식으로 개발되었습니다.


 - Windows 2000 부터 사용자 OS 에 도입된 NT 계열은 비록 GUI 기반 OS 기는 해도, DOS 이후의 호환성을 계속 유지할 수 밖에 없습니다. 따라서 조악할 쉘은 지속되었습니다.

하지만 XP 부터 시험적으로 powershell 이라는 것을 도입하여 기존의 CMD(COMMAND) shell 을 벗어나고자 한 노력은 보입니다. Vista 혹은 7 부터는 기본 탑재가 되었고 현재 버전 3은 8 부터 기본 탑재된 것 같습니다. 사실 powershell 이 좋냐 bash, tcsh 이 좋냐를 따지자는 것은 아닙니다.

powershell 역시 매우 훌륭한 쉘이지만, 그렇다고 CMD 기반하에 운영되던 모든 콘솔 어플리케이션의 생태계마저 바꿀 수는 없는 노릇입니다. 점차 바뀔 수도 있겠지만, 단기간에 그러한 문화를 바꿀 수는 없습니다. 게다가 윈도우는 일반 사용자를 위해 Console 이 아닌 GUI 위주의 설계 패턴을 따르는 어플리케이션만이 나오다 보니, UNIX 개발자에게 그 것은 매우 비생산적인 것으로 비춰지기 일쑤입니다.


 - UNIX 해커들을 유저로 받아들이고 발전한 UNIX 계열 OS 와 일반 사용자들을 유저로 받아들이고 발전한 Windows 를 직접적으로 좋다 그르다라고 판단해서는 안된다고 생각됩니다.

일부 골수 UNIX 파워 유저들이 주장하는 논리도 분명 일리는 있지만, 개발자와 사용자 간의 UX 에 대해 느끼는 편안함/익숙함은 분명 다를 수 밖에 없기 때문에 태생부터가 다른 두 OS 를 직접 비교할 수가 없습니다.


 - 윈도우가 CLI 에서 약점을 보이지만, 유닉스 계열은 GUI 에서 약점을 보인다고 생각합니다.

(Mac OS X 는 X 시리즈 이후로 UNIX 계열 BSD 기반으로 가면서 그 두 장점을 잘 조합시킨 것으로 보이지만, 많이 써보지 않은 입장에서 굳이 언급하지는 않겠습니다.)

유닉스 계열은 대부분의 개발자들이 쉘에 대해서 편안함을 느끼기에 역으로 GUI 프로그램이 도태된 측면이 있습니다. 혹자는 유닉스(X window 가 구시대적이긴 하지만)가 부족해서가 아니다, 맘만 먹으면 더 좋게 가능하다. 라고 말하지만, 따지고 보면 NT 의 powershell 을 써봤는지 묻고 싶습니다. 설사 그게 아니더라도 개발자로서 CLI 조합적인 쉘의 구현이 어려운지 묻고 싶습니다. (MS 개발자들이 바보가 아닌이상)

결국 인정해야 된다고 봅니다. 양 계열의 장단점은 기술적 차이가 아니라 사용 문화의 차이점에서 비롯되는 것을.


[결론]

- 기존 윈도우8 유저들

그냥 넘어가면 됩니다. 좀 더 쾌적하고, 익스플로러11은 확실히 빨라졌습니다.

데스크탑 모드로 바로 부팅할 수도 있습니다.

StartIsBack 이나 Start8 을 그대로 쓰신다면 또한 그냥 넘어가시면 됩니다. (8.1 지원하는대로)

다만, ActiveX 같은 고질적인 OS 버젼 업시 생기는 호환성 이슈는 고려하셔야 합니다.

제 경우 VirtualBox 같은 것을 통해 전 버젼 OS 를 가상으로 돌리니 이러한 점은 별로 중요하지 않더군요.


- 기존 윈도우7 유저들

기존 윈도우7 유저들의 입장에서 시작 메뉴가 없어진 것에 불만만 없다면, 넘어갈 만 합니다.

확실히 쾌적합니다. 쓰고는 싶은데 시작 메뉴가 아쉽다면 StartIsBack 이나 Start8 같은 시작 메뉴를 되살리는 어플리케이션을 구입(!)하시면 7 이랑 똑같이 쓰실 수도 있습니다. 무료의 시작 메뉴 되살리는 프로그램도 있습니다. 다만, 퀄리티가 다소 떨어집니다.


- 기존 윈도우Vista 유저들

Vista 는 정말 최악입니다. 일단 윈도우7로 넘어가셔야 할 것 같습니다.


- 기존 윈도우XP 유저들

PC 가 고사양이라면 7, 8 로 넘어가시는게 좋겠지만 그렇지 않다면 그냥 쓰셔도 무방합니다.

하지만 XP 의 주력은 32bit XP 기 때문에 언젠가 메모리 문제를 해결하기 위해서라도 넘어가야 된다고 생각합니다.(물론 7,8의 64bit 버젼. XP 64bit 도 있긴 한데 더 불안정함)

게임 호환성 문제의 경우에는 알아서 해야 합니다.


arrow 트랙백 | 댓글



icon iPhone 5S 등장. 아이폰 그리고 안드로이드폰
컴퓨터 | 2013. 9. 14. 15:40

2013년 9월 11일 경, 아이폰5S 가 공개되었다.

보안 관리에 실패하여 이미 알려진 스펙 거의 그대로 나온 거 말고 신선한 점은 없었다.

아래는 아이폰5S 와 경쟁사들의 안드로이드폰 스펙이다.

 


iPhone 5S Galaxy S4 LG G2 HTC One Moto X Xperia Z1
Maker Apple Samsung LG HTC Google Sony
Body Size (mm) 123.8 x 58.6 x 7.6 136.6 x 69.8 x 7.9 138.5 x 70.9 x 8.9 137.4 x 68.2 x 9.3 129.3 x 65.3 x 10.4 144 x 74 x 8.5
Body Weight (g) 112 130 143 143 130 170
Display Size 4-inch 5-inch 5.2-inch 4.7-inch 4.7-inch 5-inch
Display Type LCD Super AMOLED LCD LCD AMOLED TFT
Display Resolution 1136 x 640 1920 x 1080 1920 x 1080 1920 x 1080 1280 x 720 1920 x 1080
Display PPI 326 441 424 469 312 441
CPU A7 64-bit
M7 motion coprocessor
Snapdragon 600 /
Exynos 5 Octa
Snapdragon 800 Snapdragon 600 X8 System Snapdragon 800
RAM 1GB (?) 2GB 2GB 2GB 2GB 2GB
Storage 16/32/64GB 16/32/64GB 16/32GB 32/64GB 16/32GB 16GB
MicroSD No Yes No No No Yes
Camera (F/B) 8MP/1.2MP 13MP/2MP 13MP/2.1MP 4MP/2.1MP 10MP/2MP 20.7MP/2MP
Wi-Fi 802.11 a/b/g/n 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac
Bluetooth 4 4 4 4 4 4
GPS Yes Yes Yes Yes Yes Yes
LTE Yes Yes Yes Yes Yes Yes
NFC No Yes Yes Yes Yes Yes
Battery 1440mAh (?) 2600mAh 3000mAh 2300mAh 2200mAh 3000mAh
Battery standby 250 hours 370 hours N/A 480 hours 576 hours 880 hours
Fingerprint scan Yes No No No No No
Body material Aluminium Polycarbonate Polycarbonate Aluminium Polycarbonate Polycarbonate
OS iOS 7 Android 4.2.2 Android 4.2.2 Android 4.2.2 Android 4.2.2 Android 4.3

출처(수정됨)

이 것을 보면 아이폰은 스펙이 매우 별로인 것으로 보인다.

아이폰 5 에서 실망했지만, 5S 에서는 더 실망했다고 볼 수도 있다.

(물론 CPU/GPU 성능이 나쁘다는 것은 아니다)

 

애초에 아이폰의 독주가 처음부터 오래갈 거라 생각하지도 않았다.

개방정책의 안드로이드가 결국 점유율에서 앞설 수밖에 없다.

과거 IBM PC 와 APPLE PC 와의 전례만 봐도 그렇다.

APPLE PC 는 IBM PC 의 공개 정책에 밀려 점유율을 혹사당했다.

 

하지만, 안드로이드 점유율이 높다고 해서 회사의 이득이 큰 것도 아닐 것이다.

폐쇄 정책과 개방 정책은 장단점이 있기 때문에 일단 논외로 봐야 될 것 같다.

 

아이폰 램과 배터리 스펙은 공개되지 않았지만 대개 추정치는 맞았기 때문에 이번에도 벗어나지 않을 것이다. 화면이 작고 폰이 작으니까 배터리가 다른 폰에 비해 적은 것은 이해가 간다. 램 1GB 라는 것은 애플이 충분히 테스트해보고 내린 결론이므로 불안감과 안드로이드 한계 때문에 무작정 늘리는 안드로이드와 비교하여 나쁘다고 볼 수 없다. 안드로이드 플랫폼은 Linux 위의 자바 기반 플랫폼이므로 대부분의 어플리케이션이 자바로 개발되어있다. 자바 앱이 Native Object C 로 짜여진 아이폰 앱보다 메모리를 더 먹는 것은 어쩔 수 없다. 게다가, 애플의 폐쇄 정책은 여기서 빛을 발한다. 폐쇄 정책을 지향할 수 밖에 없는 콘솔 게임기(예. XBOX360/PS3)를 예로 보자. 현대 PC 스펙에 비해 훨씬 떨어짐에도 불구하고 같은 성능 대비 훨씬 우월한 퀄리티를 자랑한다. 프로그램을 만들어 본 사람이면 알겠지만, 하드웨어 스펙이 정해진 코딩을 하는 것과 알 수 없는 것을 코딩하는 것과는 천지차이다. 코드양을 줄일 수 있을 뿐더러, 불필요한 리소스의 양을 줄일 수 있다. 이 것은 적은 메모리와 스토리지 양으로도 더 고성능을 낼 수 있음을 의미한다.

 

아이폰은 (안드로이드폰만 써보고 아이폰을) 써보지 않은 사람이 욕하지만,

안드로이드폰은 (아이폰을 썼다가 안드로이드폰을) 써본 사람이 욕한다고 한다.

 

확실히 아이폰을 썼을 때는 안드로이드폰의 자유도 때문에 끌리는 점도 있었다.

하지만 괴랄같은 안드로이드의 배터리 효율성 때문에 위젯도 결국 안쓰게 되고, WIFI, GPS, 동기화도 일일이 수동으로 끄고 절약 모드로 전환하는 것을 보면 과연 이게 사용자 편의성인가? 하고 되묻게 된다. 오히려 아이폰의 심플함이 (최소한 모바일에서는) 더욱 사용자 편의성을 높여주는 작용을 하는 것 같다. 아이폰은 배터리를 오래 지속하려고, 옵션을 끄는 노력을 거의 하지도 않았다. 사실 거의 차이 없기도 했다. 이 것도 노하우가 아닌가 싶다.

 

PS. 스펙만 보면 위의 안드로이드폰의 배터리 대기 시간이 훨씬 길다.

하지만, S사 G...S3 을 써보며 느낀 점이지만, 안드로이드폰은 뻥튀기 스펙이라는 것이다.

최대한 벤치마크는 옵션을 다 끈 상태에서 측정할 것이다. 자유도 높은 안드로이드 폰이 뻥튀기 되기 쉽상인 원인이다. 스펙으로는 대기 시간이 더 긴데, 실상 더 짧은 경우가 많다.

(요즘은 안드로이드 배터리 용량이 더 늘어나서 장담하긴 힘들지만)

 

안드로이드폰은 절전 관리, 보안성, 불필요한 셋업으로 인한 시간 낭비, 파편화 등 아이폰에서는 유저가 생각하지 않아도 될 문제들이 많다.

 

안드로이드폰의 단점을 부각했지만, 아이폰도 문제가 있다.

지나친 폐쇄성이 어플리케이션 패치를 방해하고, 가격도 비싸다.

보수적인 결단으로 인해 화면 사이즈에 대해서도 말이 많다.

개인적으로 태블릿이 있기에 불만은 없다.

하지만, 태블릿이 없고 게임을 자주 하는 사용자로서는 불만을 가질만도 하다.

제품 자체의 단점이라기 보다는 라인업의 적은 애플의 문제라고 봐야하겠지만...

 

이러한 것을 조율할 것으로 기대됐던 윈도폰은 생각보다 보급 진척이 너무 늦어졌다.

스마트폰의 발전이 안정기에 왔기 때문에 사람들의 호기심도 많이 줄어들었지만, 그만큼 생활에 밀접하게 다가왔다고 볼 수도 있다. 각 플랫폼들은 한쪽으로 쏠림없이 안정적으로 서로를 경쟁하며 발전하길 바랄 뿐이다.


arrow 트랙백 | 댓글



[PREV] [1][···][10][11][12][13][14][15][16][···][25] [NEXT]
관리자  |   글쓰기
BLOG main image
code heart story
분류 전체보기 (74)
생활 (0)
잡담 (8)
컴퓨터 (11)
개발 (52)
Total :
Today :
Yesterday :
rss
위치로그 : 태그 : 방명록 : 관리자
코드하트's Blog is powered by Daum / Designed by plyfly.net