5.01.2026

Powershell betiklerine komut satırından parametre göndermek

Powershell betiklerine komut satırından bir bilgi (parametre, argument) göndermenin varsayılan yöntemi şöyle:

.\betik.ps1 -file D:\dosya.txt -ComputerName pc1

Burada -File parametresi küçük/büyük harf duyarlı değil. İçerde de şu şekilde işlenebilir:

param(
[string]$File,
[string]$Computername
)

Eğer -file ve -computername değerlerini parametre isimlerini/etiketlerini kullanmadan şu şekilde göndermek istersek

.\betik.ps1 D:\dosya.txt pc1

bu durumda işlerken şu şekilde bir konum belirleme mekanizması kullanmalıyız.

param(
[Parameter(Position=0)]
[string]$File,
[Parameter(Position=1)]
[string]$Computername
)

Ama eski tip DOS komutları bazen tire "-" karakteri yerine bölü "/" karekteri ile parametre göndermeyi tercih ederler.

Ya C argument dizisi benzeri şu yöntem kullanılabilir:

foreach ($arg in $Args) {
Write-Host "arg : $arg"
}

Öyle birşey istiyorum ki, betiğe -file ile, isimsiz ve hatta /f gibi bir parametre ile bile göndersek dosya.txt betik tarafından alınabilsin.

param(
    [int]$File
)

if (-not $Input -and $args.Count -ge 1) {
    if ($args[0] -match '^/f$') {
        $Name = $args[1]
    }
}

 Çoklu parametrelere girmedim.

4.01.2026

localsearch-3

Fedora'yı 43'e yükselttikten sonra durup dururken localsearch hakkında bilgi sahibi oldum. Sürekli çalışan bir süreç, localsearch-extractor-3 adında.

journalctl --user -u localsearch-3

ile bakınca çok sayıda "extractor subprocess died unexpectedly" hataları vermiş.

Hepsi localsearch adındaki bir paketin bileşenleri. Eski adı tracker/mine gibi birşey. 43 sürüm sonrası localsearch olmuş. /home klasörü altındaki dosya içeriklerini endekslemeyi amaçlıyor. Ama ben böyle otomatik arka plan işlerini sevmiyorum.

Bu işi devre dışı bırakmak için

systemctl --user stop localsearch-3.service
systemctl --user mask localsearch-3.service

komutları gerek.

Gnome aracılığıyla kapatmaktan bahsedilmiş ama galiba sürüm 43 sonrası bu ayarlar artık yok. Bunun yerine

gsettings set org.gnome.desktop.search-providers disable-external true

gibi bir yöntem var, ama sadece hizmeti devre dışı bırakmakla yetindim. 

Tamamen kaldırmak için ise

sudo dnf remove localsearch localsearch-extractors

önerilmiş. Ama ilk başta durumu izlemek için kaldırmadım, zaten sistemimde localsearch-extractors paketi de kurulu değildi. 

25.12.2025

wlms

Sanal makinelerde Windows 11 sürümleri normal şartlar altında aktivasyonu yapılmadan da uzun süreler çalışıyorlar. Ama son dönemde farkettim ki bir sanal makinem 1 saat sonunda kapandı. Olay kayıtlarına baktığımda kapatan process ile ilgili aşağıdaki sonucu gördüm.

System olay günlüğünde User32 kaynağının 1074 numaralı olayı.

C:\Windows\System32\wlms\wlms.exe sistemi kapatmış ve sebebi de Windows'un lisans süresinin sona ermesi.

wlms.exe, hizmet olarak çalışan bir süreç. Normal şartlarla servis durdurlamıyor, devre dışı bırakılamıyor ve süreç de sonlandırılamıyor. Hizmetin adı "Windows Licensing Monitoring Service", ama "Windows License Manager Service" ile karıştırmamak lazım. Onun prosesi svchost ve LocalService hesabı altında çalışıyor.

Söz konusu işletim sistemi Windows 11'in IoT LTSC EVAL sürümü.

Bu hizmetten kurtulma yolları var, örneğin bu ve şu adreste  psexec aracılığıyla hizmeti devre dışı bırakmaktan/silmekten bahsedilmiş.

psexec64 -i -s cmd.exe
sc delete wlms

Evet, hizmeti sildim ama bir süre beklemek lazım, gerçekten silinimiş bir wlms hizmetinin sonucunda bu illetten kurtulup kurtulamayacağımı görebilmek için.

24.12.2025

Anaheim

Diskimde hangi dosyaların ne tür ADS'lerinin olduğunu kontrol ediyordum:

dir -File -Recurse | % { $a = (gi $_.Fullname -Stream *  | ? Stream -ne ':$DATA').Stream;if ($a) {[PSCustomObject]@{Path=$_.FullName;Stream=$a}}}

Bu tek satırlık powershell komutu bana iki sütun halinde dosya tam yollarını ve birincil akış haricindeki diğer akışları (ADS) listeliyordu. Zone.Identifier varsayılan olarak internetten indirilen dosyaların Mark-of-the-Web işaretini vurguluyor. Ama bir dosya için farklı olarak SmartScreen gördüm. İçeriğini görmek için aşağıdaki komutu çalıştırdım:

gc -path D:\dosya.exe:SmartScreen
Anaheim

Evet. SmartScreen ADS'sinin içeriği tek kelime ve o da Anaheim. Acaba nedir bu Anaheim diye gezinirken cevabı SuperUser.com'da buldum.

SmartScreen'in Windows'un aklı başında insanlar tarafından kullanılmaması gereken bir bileşeni olduğunu biliyordum ama Anaheim'in Chromium tabanlı Edge tarayıcısının kod adını olduğunu bu sayede öğrenmiş oldum.

 

23.12.2025

Dosya gezgininde önizlemesi yapılamayan dosyalar

Windows'un dosya gezgininin önizleme özelliğini yoğun olarak kullanan bir kullanıcı, bazı pdf dosyalarında önizlemenin yapılamadığını söyledi. Önizleme yapabilmek için dosya gezginin araç çubuğundaki "Görünüm" düğmesi ile açılan menüden önizleme bölmesini seçerek pencerenin sağ tarafında dosya içeriğini açmadan (!) da izleyebileceğimiz bir alan oluşturabiliyoruz. Açmadan konusu biraz ilginç, çünkü arka planda dosya açılıyor, disk işlemleri yapılıyor ve belleğe yükleniyor. Sadece bağımsız bir pencereye sahip olmuyor ve belki de çok sayıda dosyanın olduğu bir klasörde hızlı gezinme imkanı veriyor. Neyse, önizleme bölmesinde dosya yerine görüntülenen mesaj şöyle:

Önizlemek istediğiniz dosyalar bilgisayarınıza zarar verebilir. Dosyaya ve aldığınız kaynağa güveniyorsanız, içeriğini görmek için dosyayı açın.

İlk aklıma hangi önizleme bileşenini kullanıdığını kontrol etmek geldi.

"HKEY_CURRENT_USER\.pdf\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}"

altında Varsayılan değere baktığımda {3A84F9C2-6164-485C-A7D9-4B27F8AC009E} değerini gördüm. Bunun neye karşılık geldiğini görmek için

"HKEY_CURRENT_USER\CLSID\{3A84F9C2-6164-485C-A7D9-4B27F8AC009E}"

altındaki varsayılan değeri kontrol ettim ve

"C:\Program Files (x86)\Microsoft\Edge\Application\143.0.3650.96\PdfPreview\PdfPreviewHandler.dll"

buldum. Yani Edge'in bileşenini kullanıyor. İlk aklıma gelen bunu değiştirmekti. Adobe Acrobat'ın bileşenini ayarladım, fayda etmedi.

Sonradan farkettim bu görüntüleyememe olayı her dosya için olmuyor. Acaba hangi dosyalar için oluyor diye düşünürken son dönemde internetten indirilmiş dosyalar içinde oluyor. Kontrol ettim,

Get-Item ".\dosya.pdf" -Stream Zone.Information

bir Zone.Identifier ADS akışı var. Normal şartlar altında grafik arayüzle şu şekilde dosyaların engeli kaldırılabilir. Ama bir klasör ve tüm alt klasörlerinde yer alan bütün dosyaların engelini kaldırmak için

dir -recurse | Unblock-File

ile tek seferde bütün dosyaların engelini kaldırmayı başardım.

22.12.2025

Fedora'da dnf5'e geçiş

Fedora yükseltmek için şu adımları kullanıyordum. Sürüm 41'den sürüm 43'e yükseltirken bana

sudo dnf system-upgrade reboot

yerine

sudo dnf5 offline upgrade

kullanmamı önerdi. Meğer sürüm 41'de artık bu yönde bir değişiklik olmuş. dnf5 hala tavsiye edilen kararlı yapıda değil, ama muhtemelen sürüm 45'te artık dnf yerine kullanılabilir olacak.

Diğer tüm durumlar için dnf ana komutu dnf5 ile değiştirmek yeterli:

dnf5 install firefox
dnf5 remove firefox
dnf5 search firefox
dnf5 upgrade

gibi. 

19.12.2025

dnf update sırasında çıkan "Downloading successful, but checksum doesn't match." mesajı

Buna hata mı demek lazım, uyarı mı, yoksa bilgilendirme mesajı mı?

Fedora üzerinde dnf update yaparken rastladım. Şuna benzer bir mesajdı:

$ sudo dnf check-upgrade
Updating and loading repositories:
 Fedora 41 - x86_64 - Updates                               100% |  67.2 KiB/s |  31.8 KiB |  00m00s
 Signal Messaging Devel Project (Fedora_41)                 100% |   2.3 KiB/s |   1.7 KiB |  00m01s
 Fedora 41 openh264 (From Cisco) - x86_64                   100% |   3.6 KiB/s | 989.0   B |  00m00s
 Brave Browser                                              100% |  15.5 KiB/s |   2.0 KiB |  00m00s
 ProtonVPN Fedora Stable repository                         100% |   4.8 KiB/s |   3.7 KiB |  00m01s
 Fedora 41 - x86_64                                         100% | 182.4 KiB/s |  32.7 KiB |  00m00s
 Fedora 41 - x86_64 - Updates                               100% |   1.3 MiB/s |   4.6 MiB |  00m03s
>>> Downloading successful, but checksum doesn't match. Calculated: e96bd9b4c272be2d9c7d4a656b7ae322
>>> Downloading successful, but checksum doesn't match. Calculated: e96bd9b4c272be2d9c7d4a656b7ae322

Genelde böyle bir hata olursa paket güncellenmemiş olur. Hangi paket güncellenmedi acaba diye bakmak istedim, /var/log/dnf.log dosyasına, ama burada hata olduğuna dair bir bilgi bulamadım. Bu kelime ile yaptığım aramalarda şu adreste bulduğum açıklamaya göre güncelleştirme sırasında kullanılan yansı sunucuda geçici bir uyumsuzluk olabileceği, dnf'in hata yaşanan paketi yeniden indirerek veya yansı sunucuyu değiştirerek sorunu giderebileceği belirtilmiş. Hatta böyle bir uyumsuzluğun belki de yansı sunucunun üzerindeki paketlerin diğer bir yansı üzerinden güncellenmesi sırasında karşılaşılabileceği ifade edilmiş.

Sonuç olarak tekrar dnf upgrade yaptığımda hata oluşmadı, loglarda da sorun olduğuna dair bir kayıt bulamadım. Yani geçici bir durummuş, çözülmüş.